Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I read once that one advantage of a microkernel architecture is that you can stop/start essential services like networking and filesystems, without needing to restart the whole system. But considering that Linux kernel nowadays (was it always the case?) offers the option to use modules to achieve the same effect, what are the (remaining) advantages of a microkernel?

share|improve this question
On the topic of microkernels and Linux, see also this very good answer to “Why linux is called monolithic kernel”. – Gilles Feb 26 '11 at 12:08
You can read debate on MicroKernel vs Monolithic kernel. oreilly.com/openbook/opensources/book/appa.html In this paper, Andrew Tanenbaum supports Microkernel and Linus Torvalds supports Monolithic kernel. – Bhuwan Nov 4 '15 at 10:37
up vote 26 down vote accepted

Microkernels require less code to be run in the innermost, most trusted mode than monolithic kernels. This has many aspects, such as:

  • Microkernels allow non-fundamental features (such as drivers for hardware that is not connected or not in use) to be loaded and unloaded at will. This is mostly achievable on Linux, through modules.
  • Microkernels are more robust: if a non-kernel component crashes, it won't take the whole system with it. A buggy filesystem or device driver can crash a Linux system. Linux doesn't have any way to mitigate these problems other than coding practices and testing.
  • Microkernels have a smaller trusted computing base. So even a malicious device driver or filesystem cannot take control of the whole system (for example a driver of dubious origin for your latest USB gadget wouldn't be able to read your hard disk).
  • A consequence of the previous point is that ordinary users can load their own components that would be kernel components in a monolithic kernel.

Unix GUIs are provided via X window, which is userland code (except for (part of) the video device driver). Many modern unices allow ordinary users to load filesystem drivers through FUSE. Some of the Linux network packet filtering can be done in userland. However, device drivers, schedulers, memory managers, and most networking protocols are still kernel-only.

A classic (if dated) read about Linux and microkernels is the Tanenbaum–Torvalds debate. Twenty years later, one could say that Linux is very very slowly moving towards a microkernel structure (loadable modules appeared early on, FUSE is more recent), but there is still a long way to go.

Another thing that has changed is the increased relevance of virtualization on desktop and high-end embedded computers: for some purposes, the relevant distinction is not between the kernel and userland but between the hypervisor and the guest OSes.

share|improve this answer
That is all very nice theory. If a device gets wedged somehow, the system is toast. If a driver crashes halfway though an operation, no restarting the driver will restore the system to functional state. If you want any performance at all, the drivers must be multithreaded... and the advantage of "one scheduler" is completely lost. Want performance, you have to avoid (increasingly costly) memory copies and context switches... and the "modularity" is lost. Look up sizes of some microkernels, and you'll see they comparable size and complexity to monolithic kernels with the drivers included. – vonbrand Jan 2 at 14:46

A microkernel limits the time the system is in kernel mode, as opposed to userspace, to the absolute minimum possible.

If a crash happens in kernel mode, the entire kernel goes down, and that means the entire system goes down. If a crash happens in user mode, just that process goes down. Linux is robust in this regard, but it's still possible for any kernel subsystem to write over the memory of any other kernel subsystem, either purposefully or accidentally.

The microkernel concept puts a lot of stuff that is traditionally kernel mode, such as networking and device drivers, in userspace. Since the microkernel isn't really responsible for a lot, that also means it can be simpler and more reliable. Think of the way the IP protocol, by being simple and stupid, really leads to robust networks by pushing complexity to the edges and leaving the core lean and mean.

share|improve this answer

Just take a look at x86 architecture -- monolithic kernel only uses rings 0 and 3. A waste, really. But than again it can be faster, because of less context switching.

x86 rings

share|improve this answer
The x86 ring structure is just overengineering. No practical use (except virtual machines, but that is increasingly used...) – vonbrand Jan 2 at 14:52
  1. Monolithic kernel is much older than Microkernel. It’s used in Unix . while Idea of microkernel appeared at the end of the 1980's.

  2. the example of os having the Monolithic kernels are UNIX , LINUX while the os having Microkernel are QNX , L4 , HURD , initially Mach (not mac os x) later it will converted into hybrid kernel , even MINIX is not pure kernel because device driver are compiled as part of the kernel .

  3. Monolithic kernel are faster than microkernel . while The first microkernel Mach is 50% slower than Monolithic kernel while later version like L4 only 2% or 4% slower than the Monolithic kernel .

  4. Monolithic kernel generally are bulky . while Pure monolithic kernel has to be small in size even fit in s into processor first level cache (first generation microkernel).

  5. in the Monolithic kernel device driver reside in the kernel space . while In the Microkernel device driver reside in the user space.

  6. since the device driver reside in the kernel space it make monolithic kernel less secure than microkernel . (Failure in the driver may lead to crash) while Microkernels are more secure than the monolithic kernel hence used in some military devices.

  7. Monolithic kernels use signals and sockets to ensure IPC while microkernel approach uses message queues . 1 gen of microkernel poorly implemented IPC so were slow on context switches.

  8. adding new feature to a monolithic system means recompiling the whole kernel while You can add new feature or patches without recompiling.

share|improve this answer
In (4), you are comparing apples and watermelons. The microkernel itself (by design) contains only minimal functionality, the monolithic kernel contains much more. (6) is a nice theory, it depends on how competently the pieces are developed, and how leaky the real IPC mechanism is (for performance, it can't be real "message passing"). Note (7) means a very complex handling of "message queues", thus mostly negating their advantages. For (8), in case of e.g. Linux it is certainly possible to compile a module independent of the kernel. This is routinely done for driver development, in fact. – vonbrand Jan 2 at 16:23

Windows NT (the underlying kernel to current Windows systems) started out as a quite vanilla microkernel design. Due to performance problems, more and more of the "userland" code migrated into the "micokernel"... today it's microkernel structure is vestigial.

share|improve this answer

The case is that linux kernel is a hybrid of monolithic and microkernel. In a pure monolithic implementation there are no modules loading at runtime.

share|improve this answer
it's not. the fact that modules are loaded dynamically does not change the fact, that they are run with full kernel privileges, and as part of monolithic kernel. – vartec Jan 26 '11 at 14:05
For hybrid design it would be more important wheather some drivers (for USB, Scanners, Printers and graphics) are implemented in userspace rather then kernel. The distinction is not clear and Linux can be stated as hybrid kernel as there is libusb, sane, cups and mesa - not because there is insmod and rmmod. – Maciej Piechotka Jan 26 '11 at 16:02

The terms monolithic kerneland microkernel cannot be seriously compared as they describe different aspects of kernel design (structure vs. size).

A typical monolithic kernel was the SunOS-4.x kernel and Linux is still similar, as you manually configure the content of the basic kernel.

The Solaris kernel (starting with 2.1 on 1992) cannot be called monolithic anymore as all drivers are loaded automatically on demand and only a tiny part is loaded during the initial boot.

SunOS-4.x and Solaris (SunOS-5.x) and Linux are all single context implementations. Their entire code runs in a single MMU context.

Mac OS X is based on Mach and runs as a multi context implementation with several processes separated by MMU contexts. In this concept, drivers are in separate processes and separate MMU contexts.

Many people call Mac OS X a "microkernel system", but it may be that the basic kernel is not smaller than the basic kernel from Solaris.

So it seems that it would be better to talk about single context kernels vs. multi context kernels.

share|improve this answer
MacOS runs an (essentially monolitic) BSD shim over a microkernel. No separation into separate processes at all there, not a real microkernel design. – vonbrand Jan 2 at 14:49
So you admit a design that uses at least two so called kernel processes. The term microkernel is wrong anyway as it is typically used for something that should be called multi context kernel. – schily Jan 2 at 15:22

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.