OSDev.org

I'm currently working on a conventional microkernel but I really liked the idea of a CIL-based microkernel, as Singularity and I may switch to that if I do a complete rewrite. One advantage of such OSes is that they can run on any CPU, even those that don't have any hardware protection mechanisms; the only thing that needs to be done is a rewrite of some parts of the compiler.

Exokernels are nice, but as I see it, the point (or at least one of them) of an OS is to provide application developers with a clear abstraction of the hardware, not let them do the decision-making .

JJeronimo wrote:Also, until recently, I did not understand completely the idea of microkernels. For example, I didn't understand how would it be possible to move entire kernel subsystems (process manager and/or filesystem interface) to userspace. Moving drivers seemed obvious, but moving entire subsystems seemed weird.

I haven't done user/kernel mode switching yet, which will probably cause me problems, but I can explain a little.

I have a hard disk driver, you pass it which sector to read and it returns the data from the disk there. Just imagine a simple program with a loop checking a message queue, when it gets a request it reads from the disk at the requested spot and puts the data back in the message and sends it back. It knows nothing about file systems.

Next I have an ext2 driver that runs as a process. It knows nothing about how to read from a disk drive, but it does know how to request a read from the first driver. This lets me read ext2 from any kind of source, floppy driver, usb, hard disk, etc just by requesting data from another source. You change libc to call this driver for file open/close read/write. Your libc then makes IPC messages and waits for responses, or sends the message and goes on letting the file system work async.

When you get fancy, if one of these crashes, you can restart it from the initrd image (Thats the only way to load up an executable for reading from storage). The kernel knows nothing about disk drives or file systems. Of course I don't have virtual memory so I haven't figured out how that works yet, it will probably use the same hard disk driver I have.

lhc wrote:Just imagine a simple program with a loop checking a message queue, when it gets a request it reads from the disk at the requested spot and puts the data back in the message and sends it back.

Perhaps a more efficient system here would be either to use an interrupt from the message-handling system where the disk driver is woken from a sleep state when there is a message to process. Otherwise you may have who knows how many drivers all polling for messages.

Of course, you may already have been thinking of doing that later...

Cheers,
Adam

Right now, I'm developing a monolithic kernel to learn/code/test the concepts of OS development, but my whole purpose is to write a microkernel or some kind of derivative of it

Not sure where my kernel fits into this. There is a basic module without drivers that is linked to a binary. Each driver is linked separately and uses call-gates to interface with other parts of the OS. Userland also communicates with call-gates to the kernel / drivers. In the deployment process a configuration file listing modules is used to combine kernel and drivers into a single binary. This binary can also contain userland applications (like the FreeCom command interpreter and/or an FTP-server) and proload files to a built-in drive.

First thing I decided was to make it as modular as I possibly could. Mainly because I wanted to be able to add functionality in it during runtime (by installing the module and then loading it), and because it seemed easier with my goal to make it possible for completely different GUI's to run on the same system.