OSDev.org

I'm getting to the point where I'm looking to implement a FAT driver in my Micro/Mini Kernel and I've been trying to think of strategies for doing this.
I'm expecting at a later stage I will want to support more than one filing system (I don't really want FAT as the main system but it seems like a nice simple place to start from). I'm also very sure I want to keep anything to do with hard drives and filing system out of the kernel proper.
The method I was thinking of using was having GRUB load a module for a stand-alone userspace program that would identify the file system we're trying to access and provide generalised stubs for the drive access functions. GRUB would also load a base file system ELF DLL (FAT to test with) and pass that entire DLL through to the userspace program so that it might load DLLs for the other file systems.

I'm starting to think this is a sloppy way of doing things tho, but I can't think of a decent way to support multiple File systems in a proper Micro Kernel method. Any comments?

my plan would be as such:
1. you have a "boot partition" that at least contains the system files to get the system running.
2. those system files include the FS "drivers" that you need to access other partitions.
3. your GRUB script is capable of reading the "boot partition" (and its file system) and it will load (in addition to the microkernel and the initializer program) the generic code to detect partitions, guess their types and do what's to be done with them, plus the driver for the boot partition in your OS.

I have to admit you confused me with

GRUB would also load a base file system ELF DLL (FAT to test with) and pass that entire DLL through to the userspace program so that it might load DLLs for the other file systems.

I'm not sure whether i should understand 'ELF DLL' as 'Dynamic Library in ELF format' or whatever.

Now, you might very well have several running "partition server" (one per partition type) and let them communicate with the "filename resolution" thing (roughly speaking, the VFS that translate a filename into some inode on some partition).

I am at a similar place with my own OS. My OS is centered around a device manager, which does all the recognition. In this case I invision from top down, where the drives are the top level (instead of the application layer, so to speak). The device manager recognizes the drives, but what is on them, I invisioned, to be the Partition Manager. The Partition Manager can recognize the partitions, but not the file systems. Then there is a the File System Manager, which recognizes file systems, from the partition information, from the device information, but only from installed File System Drivers. While this may seem layered in too much abstraction, I think it allows for installable\uninstallable drivers for file systems without too much work for any one manager.

Pipe.Clicker - That's pretty much what I'm suggesting however I'd like the option for users to choose the File System that boot partition is formatted with. As far as I can see this also means that GRUB has to load a base File system module (i.e. the one corresponding to the format of the Boot partition) and then pass that through to the Parititon Server so that it can then load support for the alternative partitions... (though I think it might be nice if I could have an option for on-demand loading of partition types). And yes all I meant by ELF DLL was a Dynamic Library in ELF format (though I've still not worked out quite how to deal with them yet )

Smiddy - Sounds like an interesting way of doing things, nicely modular/OO. I'm never quite sure where the balance between good OO/Modular design and over compartmentalism comes in. While I agree that each of the segments you're proposing represents a discreet element for disk access, I'm not sure how much each higher level element would duplicate from the lower level element (i.e. how many file system drivers would require access to one single partition driver as opposed to having each file system having its own partition driver internally). I'll certainly be interested to see how your tree of managers approach pans out.

Yeah, me too. I am at a stage where I can recognize all the devices. Though it is slow going with limited time to put into coding and planning. I'll let you know...

elaverick wrote: Smiddy - Sounds like an interesting way of doing things, nicely modular/OO. I'm never quite sure where the balance between good OO/Modular design and over compartmentalism comes in.

I'd be tempted to say the Devman -- Partman -- Fsman can be a good approach if you're still capable of issuing disk I/Os directly from the FS drivers to the disk drivers without having to go through each manager (e.g. managers are there to set up things, not to handle the bulk data transfers)

I think that is the idea. Instead of the other managers doing the actual work of file transfer-ing they are there to set things up, so the FSMAN doesn't have to go to the disks, read partition info, or any lowlevel prep stuff, that would be done upfront by those other managers, making a standard interface for OS API calls later. (This is a quick and simple explanation, though I think you understand the approach)