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.
To read all comments associated with this story, please click here.
Member since:2005-07-06
Member since:2005-12-03
Please take note that ring0 and ring3 are Linux-only terms, and meaningly outside discussions of the Linux kernel only
LOL, read the Intel manuals dude - it's OS-agnostic term meaning "privilege level", and has roots in MULTICS (IIRC it had 8 od them 
Besides, the NT Kernel and Mac OS X kernel aren't monolithic, but hybrid.
Wrong again - NT is even more monolithic than Linux, since it has GUI (win32k.sys) in kernel-mode. Read the relevant literature (Solomon/Russinovich for examble).
As for the MacOS - it does contain the Mach microkernel - but, as I said, it's not used as a microkernel. See what the author of upcoming "MacOS X Internals" book says on this topic:
http://www.kernelthread.com/mac/osx/arch_xnu.html
XNU's Mach component is based on Mach 3.0, although it's not used as a microkernel. The BSD subsystem is part of the kernel and so are various other subsystems that are typically implemented as user-space servers in microkernel systems.
The term "hybrid microkernel" is IMHO just a marketing propaganda dating from mid 1990s when NT 4.0 was released. NT is even more monolithic than traditional UNIXen.
Member since:2006-04-16
Member since:2005-08-18
"Please take note that ring0 and ring3 are Linux-only terms"
Uh, no. They are operating system design terms where the actual number of rings depends on the processor.
"Besides, the NT Kernel and Mac OS X kernel aren't monolithic, but hybrid."
Agreed, and so is the Linux kernel.
Member since:2005-09-30
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.
I know, I know, that's one of the reason all *miga OSs out there feels so slow... :roll:
Member since:
2005-12-03
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.