OSDev.org

Hey i'm kinda stuck in implementing this bloody fs.

I've researched and read alot of sources, most of them do something like:

mount -> search the super block -> gather information about the fs.

But my brain is in a paradox, when i'm implementing a mount function, should i be the one who writes the superblock in the first place?
Why all of the fs drivers search for ext2 information on drives?

My kernel flow is:
Bootloader loads the initrd as a grub module -> kernel gets the initrd address(which is in ext2 format) -> now i need to copy the ext2 initrd to the root device

I can't think about a good API that will help my kernel copy the initrd to the root device.

Also, i'm desinging my fs to be device independent, which means that every function the driver provides will work on a "device" object. So i'm having a hard time designing it; Should i keep information about each ext2 that is mounted on every device? every inode, every block?
Thanks.

Sourcer wrote:But my brain is in a paradox, when i'm implementing a mount function, should i be the one who writes the superblock in the first place?
Why all of the fs drivers search for ext2 information on drives?

"Mounting" a volume just means registering it in the Operating System. It doesn't actually (necessarily) modify the volume at all.

Sourcer wrote:My kernel flow is:
Bootloader loads the initrd as a grub module -> kernel gets the initrd address(which is in ext2 format) -> now i need to copy the ext2 initrd to the root device

I can't think about a good API that will help my kernel copy the initrd to the root device.

I'm not sure what you mean by "root device", and I don't know why you would want to copy your initrd to it.

Sourcer wrote:Should i keep information about each ext2 that is mounted on every device? every inode, every block?

It's up to you. The more information you keep in memory, the faster your system will be. But the more you fill up system memory, the more you will need to swap data to disk, which will make it much slower. So it's a matter of building a system that balances all of its resources in a way that maximizes overall performance.

SpyderTL wrote:

Sourcer wrote:But my brain is in a paradox, when i'm implementing a mount function, should i be the one who writes the superblock in the first place?
Why all of the fs drivers search for ext2 information on drives?

"Mounting" a volume just means registering it in the Operating System. It doesn't actually (necessarily) modify the volume at all.

Sourcer wrote:My kernel flow is:
Bootloader loads the initrd as a grub module -> kernel gets the initrd address(which is in ext2 format) -> now i need to copy the ext2 initrd to the root device

I can't think about a good API that will help my kernel copy the initrd to the root device.

I'm not sure what you mean by "root device", and I don't know why you would want to copy your initrd to it.

Sourcer wrote:Should i keep information about each ext2 that is mounted on every device? every inode, every block?

It's up to you. The more information you keep in memory, the faster your system will be. But the more you fill up system memory, the more you will need to swap data to disk, which will make it much slower. So it's a matter of building a system that balances all of its resources in a way that maximizes overall performance.

My initrd contains all the OS's toolchain(userspace programs) and the base directories.(Unix directories like /bin, /dev). Maybe i misunderstood the purpose of the initrd, but isn't it supposed to be loaded first to the RAM, then to the root device for future booting?(root device is the device that the kernel is "installed" on)

The initial ramdisk is the disk image you initially mount on /, then you either continue with it or mount a new partition on / (aka switch_root and pivot_root on some UNIX(-like) systems).