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.
ext2 fs
Re: ext2 fs
"Mounting" a volume just means registering it in the Operating System. It doesn't actually (necessarily) modify the volume at all.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?
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: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.
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.Sourcer wrote:Should i keep information about each ext2 that is mounted on every device? every inode, every block?
Project: OZone
Source: GitHub
Current Task: LIB/OBJ file support
"The more they overthink the plumbing, the easier it is to stop up the drain." - Montgomery Scott
Source: GitHub
Current Task: LIB/OBJ file support
"The more they overthink the plumbing, the easier it is to stop up the drain." - Montgomery Scott
Re: ext2 fs
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)SpyderTL wrote:"Mounting" a volume just means registering it in the Operating System. It doesn't actually (necessarily) modify the volume at all.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?
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: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.
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.Sourcer wrote:Should i keep information about each ext2 that is mounted on every device? every inode, every block?
Re: ext2 fs
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).
"If you don't fail at least 90 percent of the time, you're not aiming high enough."
- Alan Kay
- Alan Kay