Modular Monolithic Kernel versus Micro-kernel

[chris]

Can a modular monolithic kernel yield some of the micro-kernels abilities such as Improved stability (If say, the filesystem module crashs, can it be restarted like a micro-kernel "server" can)?

[Solar]

Short answer: No, IMHO.

Long answer: What "crashes" is basically the address space. If the address space contains all of the kernel (as implied by "monolithic"), the kernel crashes as a whole. "Modular" in the monolithic context usually means that the code for e.g. FS support is placed in a seperate binary, which however is loaded into the same address space. (At least that's the case for e.g. GRUB kernel modules.)

But: Building a microkernel does not automatically give you restart capabilities. If a filesystem module crashes, you have stale file handles and a potentially corrupted on-disk filesystem. Both have to be dealt with, and I doubt this can be done 100% transparent to the application.

[BI lazy]

Howdy solar!

Well ... this restarting capability of micro kernel servers is as solar says, very limited. In case of a file service (I deal with services instead of servers in BlueIllusion), You lose all the Process data and file pointers linked to the processes having opened some files, which point to some inodes and blablabla ... or how do you handle this: the file service craps out in the middle of write back of the inode bitmap? Funny stuff this is.

So I don't think, the micro kernel stability is a kind of jack-of-all-trades. It hase trade-offs: in case of filesystem, you'd have to shut down all the processes too and start off the file system again. You just can't guarantee a safe envirponment for the processes anymore if such a crucial service craps out.

Just my two cents...

[Pype.Clicker]

and what about a ?k where the core could be able to "replay" the client requests that weren't properly stored ?

as all the client deals with is handles, all we need for safe service respawn is the ability to get a new valid 'client stub' in the new server given informations on the old proxy (doh. am i using COM terminology already .. i shouldn't have read that book ... i knew it).

Concerning the "filesystem coherency", this is a matter of journalling your accesses, exactly as for unexpected system reboot.

Let's say you have the following:
- clients that can do write(file_handle,data,options)
- server that can respawn, check and replay the journal so that the filesystem (on disk) remains consistent ...
- message dispatcher that can tell whether a file_handle is still valid or not, and call new_handle=fileserver::open(filename, mode), fileserver::seek(new_handle,client_saved_position)

All you still need is to re-send "write" messages that has not been acknowledged when you receive the "SERVER_RESPAWN" message from the microkernel ...
This requires the "message dispatcher" (proxy) at the client's side to keep track of which "read" and "write" requests have been acknowledged and which haven't.

[chris]

Very interesting info guys! I still think I like the Micro-kernel. Although, I don't really know to design/write one properly (ie. starting the services or servers in their own address space). I was just basicaly wondering if Tanenbaums's OS: D&I discuss's some of this.

[Solar]

@ Pype:

All very true. But that's the point: Microkernels allow you to do all that stuff - it doesn't come for free just because your FS has an address space of its own.

[Pype.Clicker]

of course ... I was taking that for well-known as having the X-server in a separate user process doesn't allow my X application to be kept alive when the server crashes and restart ...

[BI lazy]

Hmmm .... restart safety ....

Well, I point you at Transaction monitors like CICS or OpenUTM, which provide this Feature (keeping all the crucial data in areas called transaction areas, which are structures written to a file at every call of another UTM-Module via message.) They are transaction safe and therefore can restart at the point where they have crapped out previously - if not, it is a programming bug and has to be tracked down.

I for one don't think that it is the task of the operating system to grant absolute restartability of user processes if a crucial system service craps out.

Sure, you can grave each and every action into files, but won' t this slow down the whole beast? The same goes for storing all this crucial data in a set aside memory area kept save away by the kernel itself and handed out at needs.

stay safe

[Joe7]

BeOS can do that, correct? If I remember it correct when I used BeOS and if one of module gets crash and it can be restart by itself.