Microkernel
In computer science, a microkernel (often abbreviated as μ-kernel) is the near-minimum amount of software that can provide the mechanisms needed to implement an operating system (OS).
They feared that each installation would require a different operating system so they started to investigate novel and more general ways of creating software for the RC 4000.
The lack of memory protection, considered in other respects a flaw, allowed this kernel to have very high message-passing performance because it did not need to copy data while exchanging messages between user-space programs.
The first microkernels, notably Mach created by Richard Rashid, proved to have disappointing performance, but the inherent advantages appeared so great that it was a major line of research into the late 1990s.
[10] However, during this time the speed of computers grew greatly in relation to networking systems, and the disadvantages in performance came to overwhelm the advantages in development terms.
[citation needed] Many attempts were made to adapt the existing systems to have better performance, but the overhead was always considerable and most of these efforts required the user-space programs to be moved back into the kernel.
As of 2012[update], the Mach-based GNU Hurd is also functional and included in testing versions of Arch Linux and Debian.
[citation needed] Using a more pragmatic approach to the problem, including assembly code and relying on the processor to enforce concepts normally supported in software led to a new series of microkernels with dramatically improved performance.
Throughout the early history of Unix, kernels were generally small, even though they contained various device drivers and file system implementations.
In theory, the microkernel design allows for easier management of code due to its division into user space services.
Shared memory is, strictly defined, also an inter-process communication mechanism, but the abbreviation IPC usually refers to message passing only, and it is the latter that is particularly relevant to microkernels.
Most or all support for peripheral hardware is handled in this fashion, with servers for device drivers, network protocol stacks, file systems, graphics, etc.
Jochen Liedtke assumed the design and implementation of the IPC mechanisms to be the underlying reason for this poor performance.
[citation needed] In a series of experiments, Chen and Bershad compared memory cycles per instruction (MCPI) of monolithic Ultrix with those of microkernel Mach combined with a 4.3BSD Unix server running in user space.
[16] Liedtke later refined Chen and Bershad's results by making an observation that the bulk of the difference between Ultrix and Mach MCPI was caused by capacity cache-misses and concluding that drastically reducing the cache working set of a microkernel will solve the problem.
[17] In a client-server system, most communication is essentially synchronous, even if using asynchronous primitives, as the typical operation is a client invoking a server and then waiting for a reply.
Furthermore, a client could easily mount a denial-of-service attack on a server by sending a request and never attempting to receive the reply.
As a consequence, the trend is towards not providing arbitrary timeouts, but only a flag which indicates that the IPC should fail immediately if the partner is not ready.
The necessary servers are started at system startup and provide services, such as file, network, and device access, to ordinary application programs.
Additionally, many "crashes" can be corrected by simply stopping and restarting the server, which would not be feasible if the entire kernel had to reboot.
However, part of the system state is lost with the failing server, hence this approach requires applications to cope with failure.
Recently, an increasing number of computers feature IOMMUs, many of which can be used to restrict a device's access to physical memory.
As a microkernel must allow building arbitrary operating system services on top, it must provide some core functionality.
At a minimum, this includes: This minimal design was pioneered by Brinch Hansen's Nucleus and the hypervisor of IBM's VM.
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.
A key component of a microkernel is a good IPC system and virtual-memory-manager design that allows implementing page-fault handling and swapping in usermode servers in a safe way.
[17] Liedtke demonstrated with his own L4 microkernel that through careful design and implementation, and especially by following the minimality principle, IPC costs could be reduced by more than an order of magnitude compared to Mach.
Furthermore, performance does not seem to be the overriding concern for those commercial systems, which instead emphasize reliably quick interrupt handling response times (QNX) and simplicity for the sake of robustness.
[34] This has led to what is referred to as third-generation microkernels,[35] characterised by a security-oriented API with resource access controlled by capabilities, virtualization as a first-class concern, novel approaches to kernel resource management,[36] and a design goal of suitability for formal analysis, besides the usual goal of high performance.
This provides a guarantee that the properties proved about the API actually hold for the real kernel, a degree of assurance which goes beyond even CC EAL7.
