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.
Thread beginning with comment 115532
To view parent comment, click here.
To read all comments associated with this story, please click here.
Brendan
Member since:
2005-11-16

Hi,

What if the soundcard driver gets corrupted and starts
DMA to a random page of memory that was actually some
filesystem's pagecache[*]?


Then you're screwed regardless of what you do. PCI bus mastering is the only thing a micro-kernel can't protect against (I've never found anything that can protected against it at least, but AMD's virtualization hardware might help - I haven't looked into it so I'm not sure). For the ISA DMA controllers it's easy to force drivers to use a kernel API where decent checking can be done (if you haven't guessed, I'm more for slightly largish micro-kernels than for minimalistic nano-kernels).

What if a driver goes haywire and starts sending the wrong IPC messages down the pipe?

It's standard programming practive (or at least it should be) to always check input parameters before doing anything, especially if these input parameters come from elsewhere (e.g. function parameters, command line arguments, message contents, environment variables, etc). All "message receivers" should also be able to check who sent the message. If the message still passes all of this, then the receiver might do something that isn't desired, but it's very unlikely this would lead to major problems.

I don't think so. You have to have at least 3 devices
and 3 different drivers and perform checksumming across
all data that comes out of them if you really want to
be able to discard invalid results from a single
driver. Or you could possibly store checksums on disk,
but if you don't trust a single driver...


You are right - 2 redundant drivers/services can recover from detectable failures, but 3 are required to detect some types of failure. For a failure like completely crashing (page fault, general protection fault, etc) 2 drivers/services are enough, but for checksumming you need at least 3.

I think in general it would be far better to go with
RAID, or a redundant cluster wouldn't it?


Regardless of how good it is, hardware RAID has at least 2 single points of failure (the device driver and the controller). Having entire redundant computers (or a redundant cluster) is an option for all types of kernels (but it's not so cheap).

A microkernel can fail too, end of story. If you need
really high availability, you need failover clusters.


Of course - but it's easier to find/fix bugs in something small, that isn't cluttered full of every device driver imaginable.

And within a single machine, I happen to think
hypervisor/exokernel + many monolithic kernels is a
much nicer solution than a microkernel.


You mean like running 8 versions of Vista on the same machine so that you can edit text files without worrying about messing up your web server? Hardware manufacturers would love the idea (just think of the extra sales)!

Reply Parent Score: 1