OSDev.org

Hi,


I am writing a micro kernel .... I wrote most of the IPC ( message passing )+ scheduling ( round robin ) + IO drivers ( keyboard, video and RAM disk are enough right now ) and I was wondering how I would write file systems and memory management ...

Since file systems and memoy management, in a micro kernel approach ( wich is what i am doing ), are completely separeted processes from the kernel, how can I fork a memory management process if forking a process is a memory management responsabiliity ? How can I mount, find and bring the FS code ( text, instruction ) to memory if I don't even have a mounted file system ( since thi s is FS responsability ) ?

Hehe ..

I know this sound bizarre, but I still don't have a good answe for these questions ...

Any help is welcome,

Thanks in adavance, samuelgoto

Hi,

mel wrote: Since file systems and memoy management, in a micro kernel approach ( wich is what i am doing ), are completely separeted processes from the kernel, how can I fork a memory management process if forking a process is a memory management responsabiliity ? How can I mount, find and bring the FS code ( text, instruction ) to memory if I don't even have a mounted file system ( since thi s is FS responsability ) ?

For memory management, I'd do physical memory management (keeping track of which pages are free) and linear memory management primitives (allocate page, free page, create page directory, etc) inside the micro-kernel. Things like determining which pages to swap to disk and memory mapped files could be done anywhere (although I do that in the kernel too). For an example of doing all memory management outside of the kernel, find some information on L4 (documentation for L4's memory management should be easy enough to find).

For the file system code (and device drivers for floppy, hard disk, CD-ROM, etc) it's best to load them into memory during boot (the same as you'd load the kernel itself).

The method I use is that the boot loader loads a boot image into memory, where the boot image contains a pile of files (including the kernel). The kernel itself has a "kernel module" for handling the VFS (Virtual File System). The VFS caches files, and during boot everything in the boot image is inserted into the VFS cache. From this point, normal file I/O works - files can be loaded (and saved) from/to the VFS cache (which works like a RAM disk).

Once the VFS cache (RAM disk) is working, device drivers and file system code can be loaded from the virtual file system and started. These things register themselves with the VFS and increase the amount of things the VFS can get data from. It also means that file system code and device drivers can load configuration files and things from the VFS before any file systems are ready.

Once file systems are started the VFS code compares what is cached (from the boot image) to what is on disk, and flushes the cached data to disk if necessary. This makes OS installation much simpler. For example, the user can boot the OS and the OS will automatically detect which disk drivers to start. From here the user can partition the disks, format them and then mount them, and the VFS code will automatically store files from the boot image onto the mounted file system/s. It also means that the OS can go from nothing (a bare machine) to fully installed without needing a reboot (or complicated installation code/scripts).


Cheers,

Brendan