Editing Microkernel (section)

==Essential components and minimality==
As a microkernel must allow building arbitrary operating system services on top, it must provide some core functionality. At a minimum, this includes:
* Some mechanisms for dealing with [[address space]]s, required for managing memory protection
* Some execution abstraction to manage CPU allocation, typically [[thread (computing)|threads]] or [[scheduler activations]]
* [[Inter-process communication]], required to invoke servers running in their own address spaces

This minimal design was pioneered by [[Brinch Hansen]]'s [[RC 4000 Multiprogramming System|Nucleus]] and the hypervisor of IBM's [[VM (operating system)|VM]]. It has since been formalised in Liedtke's ''minimality principle'':
<blockquote>A concept is tolerated inside the microkernel only if moving it outside the kernel, i.e., permitting competing implementations, would prevent the implementation of the system's required functionality.<ref name="Liedtke_95" /></blockquote>
Everything else can be done in a usermode program, although device drivers implemented as user programs may on some processor architectures require special privileges to access I/O hardware.

Related to the minimality principle, and equally important for microkernel design, is the [[separation of mechanism and policy]], it is what enables the construction of arbitrary systems on top of a minimal kernel. Any policy built into the kernel cannot be overwritten at user level and therefore limits the generality of the microkernel.<ref name="Liedtke_96"/> Policy implemented in user-level servers can be changed by replacing the servers (or letting the application choose between competing servers offering similar services).

For efficiency, most microkernels contain schedulers and manage timers, in violation of the minimality principle and the principle of policy-mechanism separation.

Start up ([[booting]]) of a microkernel-based system requires [[device driver]]s, which are not part of the kernel. Typically, this means that they are packaged with the kernel in the boot image, and the kernel supports a bootstrap protocol that defines how the drivers are located and started; this is the traditional bootstrap procedure of [[L4 microkernel family|L4 microkernels]]. Some microkernels simplify this by placing some key drivers inside the kernel (in violation of the minimality principle), [[LynxOS]] and the original [[Minix]] are examples. Some even include a [[file system]] in the kernel to simplify booting. A <!-- In other cases,  [[GNU GRUB]] for example, (This is NOT according to GRUB wiki) --> microkernel-based system may boot via multiboot compatible boot loader. Such systems usually load statically-linked servers to make an initial bootstrap or mount an OS image to continue bootstrapping.

A key component of a microkernel is a good [[Inter-process communication|IPC]] system and virtual-memory-manager design that allows implementing page-fault handling and swapping in usermode servers in a safe way. Since all services are performed by usermode programs, efficient means of communication between programs are essential, far more so than in monolithic kernels. The design of the IPC system makes or breaks a microkernel. To be effective, the IPC system must not only have low overhead, but also interact well with CPU scheduling.