OSDev.org

Hello. I've been designing my OS for quite some time now, and was wondering what the best way to do this might be. You see, after my kernel loads, I need file system access to get to specialized drivers. I then need those file system drivers to determine which devices they control, and then mount to a "/vfs/dev/<storage-type-name>/<device-number>[/<partition-number>]" directory. E.g., /vfs/dev/hd/0/0; or /vfs/dev/rd/sdcard/0. The kernel, knowing that one of the storage device directories has changed, would then mount said storage device into the root directory (under a possibly different name). For example, an ext4 FS driver might load, determine that it controls /vfs/dev/hd/0/0 and take control of said block-device file. My kernel would then mount that to /hd0. But, I digress.

What I'm trying to get at is, in what order (and to a minimal extent, how) should my kernel load the file system drivers? Would it be wise to have a kernel initialization package module which contains a configuration file and a copy of a specific file system driver? (The configuration file would specify what device the rest of the drivers are stored on, and the file system driver in the package would be for said device.)

Everything after the part where the file system drivers are loaded is trivial. It's getting to that trivial part that I'm unsure of. I've thought up several methods to do so, but the example given above is the best one I've come up with thus far. So, I'm fairly interested in hearing what you guys have to say. I just want to write this system once, and not have to redesign it later.

Thanks in advance, all help and constructive criticism is appreciated.

Cheers,
-naota

The only real way of getting filesystem drivers up is to have at least one in the kernel already, from where you can load the others. Linux does this either through an initrd (which is in a deliberately very simple format) or, if you know which filesystems you're going to use, by compiling the appropriate drivers in directly (but this takes up extra space in memory, and not just on disk, if you aren't using the drivers)

For a reference, my setup is this:

In th kernel, I have drivers for a device filesystem (like /dev/), and also the required VFS functions, controlling inodes, and storing callbacks for the FS driver. Then, I have an initrd that GRUB loads for me, which my kernel parses and loads the files contained into a RamFS (driver for which is also built in). The RamFS is very simple, just using kmalloc to store the files and using the VFS's inode tree for file lookup.

Then, my kernel parses the mod_config file, which specifies some modules to load (like the hard drive access module). My device management systems allows access to the hard drive, and since /dev/ is in the kernel already, this allows filesystems to access devices in /dev/ from the very start, even before any drivers have loaded.

The initrd also contains a module for ext2, which is loaded and registered as a filesystem...then I mount the root device on a directory that is created (/mnt) and then switch to it.

The way I see it, is that it's important to standardize basic interfaces from as early as you can; so I have some simple drivers directly in the kernel to facilitate the ease of loading other drivers. This goes especially for access to devices...while you can access them by say, a function call like (dev_num, command, argument, buffer, whatever), standardizing access across the whole kernel is much simpler.

-JL

Okay, thanks. I thought it might be something like that, just wasn't sure if it was the best way to go about it.

Cheers,
-naota

In my design, the initialization code uses a function provided by the boot loader to load the system configuration file, which lists all the drivers installed in the system. Drivers marked as boot drivers are loaded along with any other components they depend on. Typically, these are the drivers for the disk where the OS is installed, and the devices that it is connected to, as well as the file system used on the partition. Then, the system has enough drivers to begin starting up. Boot drivers can use the limited boot file system to load additional files if needed in their initialization code. Afterwards, the boot file system is disabled and the system begins starting devices whose driver is a boot driver. When these have completed starting, the storage class driver will have identified the boot volume and called the correct file system driver to initialize the file system, which will now become the boot file system.