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 115304
To read all comments associated with this story, please click here.
And why I hate microkernels..
by ivans on Sun 16th Apr 2006 17:04 UTC
Member since:

Oh joy. Here it goes again - the ever lasting story of how never-succesful academic bullshit called "microkernel" never made it into the mainstream OSes. And how world would have been a safer place, with no drivers fooling around in ring0, if Cutler/Torvalds/whomever had listened to mr. Tanenabaum and alike.

The microkernel propaganda is mostly composed of three common FUDs:

1) microkernels are more "stable", because having ALL kernel code besides scheduler/dispatcher, IPC and some basic interrupt routing in ring3 (aka user-mode)

WRONG. If any crucial OS component (such as Memory Manager or FileSystem driver) fails - the whole OS fails as well. Being in ring0 (like the monolithic kernels do it) makes it just crash faster.

2) microkernels are more modular/maintanable/simple/blahblah

Writing modularized code is the basic tenet of software engineering, and it's called separation of policy from mechanism, and has NOTHING to do with the kernel being monolothic or not.

For example - Linux kernel is highly modular, either from the standpoint of compile time flags, or dynamically expandable functionality via LKMs. Just look at the design goals behind the VFS(used by any filesystem driver) and LSM (Linux Security Modules - utilized by SELinux, DTE..) to know what I mean..

NT kernel (W2K, WS2K3, XP, Vista..) is also very modular - the basic kernel schedulable primitives are encapsulated into so-called "executive components" (MM, I/O, essentialy anything besides scheduler) but are still all being compiled into one big fat binary called NTOSKRNL.EXE. The point is that it's the code that separates different abstraction policies, not the postcompiled modules organization.

3) It's easier to write drivers for microkernel.

Because they should, by definition, be living in ring3, and could be debugged in gdb or VS, and not in null-modem connected kernel debugger :-) And that's the reason why printer drivers are in userland ever since W2K, why Vista will have so-called UMDF (User-Mode Driver Foundation) that will enable most, for OS nonessential, cheap hardware to have it's drivers running in ring3 (if you have XP SP2, check out the WDFMGR.EXE's process description ;)

And the cons against microkernel? Spending most of your CPU cycles doing context switches and IPC for simple stuff such as page fault handling and ISR dispatching.. That's the reason why there are NO general-purpose commercially-successful microkernel OSes - that's right, all Win NT-based, Linux, *BSD, Solaris, HP-UX, AIX, MacOS (aka Darwin - it contains Mach but it is not used as a microkernel, there are the FBSD, IOKIT and drivers stuff in ring0 too!) are monolithic. And those who aren't, (QNX, EKA2 - SymbianOS nanokernel) are so not because of the "increased stability and security", but because it enables them to have predictable interrupt latency.

Sorry for bad english.

Reply Score: 5