Linked by Thom Holwerda on Sun 16th Apr 2006 15:36 UTC
OSNews, Generic OSes Right in between a car crash and Easter, I knew I had to write a Sunday Eve Column. So here I am, digesting vast quantities of chocolate eggs (and I don't even like chocolate), craving for coffee (for me about as special as breathing), with the goal of explaining to you my, well, obsession with microkernels. Why do I like them? Why do I think the microkernel paradigm is superior to the monolithic one? Read on.
Permalink for comment 115503
To read all comments associated with this story, please click here.
Member since:

Consider a dodgy driver or service that occasionally writes to random addresses.

In a traditional monolithic system, the driver/service would be implemented as part of the kernel and can trash anything that's running on the computer - nothing will stop if from continuing to trash things, and nothing will help to detect which driver or service is faulty.

On a basic micro-kernel the driver/service can't effect anything else in the system, and sooner or later it'd generate a page fault and be terminated. This makes it much easier to find which driver or piece of software was faulty, and means that damage is limited.

In this case, you're still partially screwed because everything that was relying on that driver or service will have problems when that driver/service is terminated. This isn't always a problem though (it depends on what died) - for example, if the driver for the sound card dies then no-one will care much. If the video driver dies then the local user might get annoyed, but you could still login via. network and things like databases and web servers won't be effected.

The more advanced a micro-kernel is the more systems it will have in place to handle failures.

For example, if the video driver dies the OS might tell the GUI about it, try to download/install an updated driver, then restart the video driver and eventually tell the GUI that the video is back up and running. The user might lose video for 3 seconds or something but they can still keep working afterwards (and there'd hopefully be an explanation in the system logs for the system administrators to worry about).

Another way would be to use "redundancy". For example, have one swap partition on "/dev/hda3" and another on "/dev/hdc3" with 2 seperate disk drivers. Writes go to both disk drivers, but reads come from the least loaded disk driver. In this case the system would be able to handle the failure of one swap partition or disk driver (but not both). With fast enough networking, maybe keeping a redundant copy of swap space on another computer is an option..

The point is that for monolithic kernels you don't have these options - if anything in kernel space dies you have to assume that everything in kernel space has become unreliable, and rebooting is the only reliable option (if the code to do a kernel panic and reboot hasn't been trashed too).

Most developers of monolithc systems will say that it's easier to make their drivers and services bug free than it is to implement systems to recover from failures. They may be right, but it might be "wishful thinking" too...

Reply Parent Score: 2