OSNews

Yes. It's a true microkernel using only a mere 4000 line of code or so. Everything including file server, device drivers, UNIX Server, etc all run in userspace versus Kernel space. This means that nearly everything can be upgraded while the system is live.

The Kernel itself only handles basic hardware IPC (inter-process communication) which allows the kernel what 'modules' can access what piece of hardware and pieces from other modules. The end result is that buffer overflows are a thing of the past (in theory)

With Linux, most BSDs, Windows... etc all run with drivers compiled and running in Kernel space. This allowed ANY driver to access ANY piece of hardware or pieces of other drivers. The fundamental flaw going this route is that any single piece of code-error (even 1 line) in a driver can bring down an whole system. Running drivers in userspaces allows the reincarnation server to kill the running driver, restart it and log what driver did what without taking the whole system down. Windows crashes, about 60-80% of the time or so, are caused by bad driver code. It's also believed that drivers carry about 3-7x more bugs than ANY other piece of code in the OS.

Windows NT had tried going this route when it was first released, but failed miserably. Vista is another example of Windows going this route (to each his own on how well they are doing). DragonflyBSD and Darwin(Mac OSX Kernel) are examples of "Hybrid" kernels where some parts (like certain drivers) are run in kernelspace, leaving other parts running in userspace.

Hope that helps.

edit .. FUSE on linux is running Filesystem in Userspace.
Linus seems to dislike microkernels considerably, claiming they cause much unnecessary overhead. 5000 IPC calls, on a 2.2ghz Athlon, expect to only use about 1% of the CPU (not very much at all). Each person has their opinion on performance:security/stability. I'm not campaigning against Monolithic kernels (as I'm a big believer in OpenBSD and how the project is run/audited), but as more and more drivers and features are added to kernels, the more and more code is added along with more and more bugs.

Edited 2008-08-13 19:01 UTC

vista is just another incarnation of NT iirc...

and i dont know if drivers running in user space makes things more secure. that would depend on what access rights those user space drivers have...

if it has the equivalent of root access, its only marginally better then linux or similar in that these days its less interesting to crash something then to zombify something.

also, microsoft tried microkernel, found performance to be to bad on some of the drivers, moved those back into kernel space, and now have moved some out again in vista.

i think the big issue with drivers are when they are closed source so that when a driver do something bad, one cant figure out what it did, only that it did something.

thats why one have tainted driver markers in the linux kernel log, for when something like the closed up nvidia drivers do something bad.

as for linus's opinion on micro-kernels, maybe they have changed over the years, maybe not. but i wold say that using improvements in hardware to justify lower performance in software is lazy at best, the dark side at worst (see current vista hardware demands)...

Edited 2008-08-13 19:05 UTC

Thank you for this post.I learnt much as it was very informative.

It's funny. Even after all this time (eighteen years after Torvalds's and Tanenbaum's e-mail exchange) people just don't get that IPC in a kernel is colossally expensive. Until we get hardware that has unlimited resources and where there is no cost in increasing the layers in a system, microkernels are a total waste of time in all but a very small context of uses, and their use is even debatable there. Embedded devices with limited resources, such as Tanenbaum's TV example in the argument, is even funnier. It still matters, and will matter for a very, very long time.

IPC and distributed system are also unbelievably complex to get right as anyone knows, which means I have always laughed at the simplicity arguments of microkernel proponents. You also have to do lots of ludicrously expensive things such as copy data. There are lots of implications involved.

Think about this: the reason why people talk about microkernels as great is because they are assuming that they'll fail, and assuming failure, before a single line of code is written and assuming that everything will be fine because they have a microkernel. Kernels are a unique piece of software (it's where everything starts, obviously) where that kind of attitude is a tad dangerous. It's really a self-fulfilling prophecy.

I have never seen one piece of evidence that shows me that in all the uses that kernels have in the world, microkernels make an appreciable positive difference in reliability, especially versus more immediate performance concerns.

That really strikes at the heart of the matter - there is no evidence that microkernels actually matter or make a difference in pretty much all the uses out there. The part of the article where we get to see that Tanenbaum still has no practical sense whatsoever is where he talks about using a microkernel to keep a TV running. It's one of those hypothetical, academic things of no practical use. Well, people have been doing that for a long time now, and what they generally do is cut down a kernel (usually Linux these days) to the bare minimum to run on hardware that has a limited set of uses - which is how QNX is used anyway. If we saw a microkernel run on systems that do many different things, then we'd see how reliable it really is - but we don't.

Certainly in a device like a TV, of more paramount importance is the general responsiveness of the system, and the failure of a TV set is almost always a result of the software running on top (or the hardware), not the kernel, and that's the part with all the functionality. Even then though, if one part of your kernel fails it is still a failure (it's a kernel!) which usually takes down most of the system regardless, and this is what Andrew still fails to get conceptually about them. You just end up going round in large circles of complexity looking for mythical holy grails of simplicity, reliability and security.

I actually feel pretty sad for him that he still thinks that way after all this time, and sad for most microkernel components who haven't paid attention to practice rather than academic theory.

They're not hybrid kernels, they are monolithic kernels. Being a microkernel implies a specific structure, and running a few things in userspace is not a qualifier. None of the kernels above are microkernels because they've discovered that performance an complexity sucks. They're problems that Apple has bypassed like a Christmas tree with Mach.

Whenever you see the name 'hybrid kernel' it's a kernel that has generally started off with lot of idealistic microkernel ideas and then discovered that, practically speaking, they suck in the real world. Either that, or you've got a monolithic kernel that wants to pretend it has some of the marketing advantages of microkernels. That's an easy definition.


If true, that should tell you something about the driver and kernel development model there. A microkernel isn't going to help you because focusing on single drivers and worrying about what they do drags down the aggregate system as a whole.

Edited 2008-08-14 10:15 UTC

It confused Minix3 with OpenBSD

the idea behind Minix3 is "highly reliable", not "secure".

well in that case...

Agreed. However, the way the code is audited on a continual basis, fixing security bugs (buffer overflows, etc) causes the kernel to run more reliably too. Still, any updates to the kernel causes the system to require a reboot.

Same can be said for Minix3.. Running it more reliably, by restricting modular access, CAN make the OS more secure by disallowing modules to take over the system and do anything they'd like.. Less chance for exploitation.