Wikipedia

Microkernel

This is an old revision of this page, as edited by Nagle (talk | contribs) at 03:45, 7 March 2006 (Fix KeyKOS). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

A microkernel is a type of kernel which consists of a simple abstraction over the hardware, with a set of primitives or system calls to implement minimal OS services such as address space management, thread management, and inter-process communication. All other services, those normally provided by the kernel such as networking, are implemented in user-space programs referred to as servers.

Graphical overview of a microkernel

Essential components of a microkernel

The minimal set of services required in a microkernel seems to be address space management, thread management, inter-process communication, and timer management. Everything else can be done in a user program, although in a minimal microkernel, some user programs may require special privileges to access I/O hardware. A few operating systems approach this ideal, notably QNX and IBM's VM.

Most microkernel systems don't go quite that far. Most put at least some device drivers in the kernel. LynxOS is an example. Most also put a file system in the kernel.

A key component of a microkernel is a good inter-process communication system. Since many services will be performed by user programs, good means for communications between user programs are essential, far more so than in monolithic kernels. The design of the inter-process communication system makes or breaks a microkernel. To be effective, the inter-process communication system must not only have low overhead, it must interact well with CPU scheduling.

Start up, or booting, of a microkernel can be difficult. The kernel alone may not contain enough services to start up the machine. Thus, either additional code for startup, such as key device drivers, must be placed in the kernel, or means must be provided to load an appropriate set of service programs during the boot process.

Some microkernels are designed for high security applications. EROS and KeyKOS are examples. Part of secure system design is to minimize the amount of trusted code; hence, the need for a microkernel. Work in this direction, with the notable exception of systems for IBM mainframes such as KeyKOS and IBM's VM, has not resulted in widely deployed systems.

Tradeoffs in microkernel design

Originally the kernel was fairly small, but as the capability of computers grew the number of devices the kernel had to control also grew. Many of these no longer fit into a model based on files; for instance, networking can't be effectively treated as a file. More and more code was included into the kernel to handle these sorts of tasks, and the kernels grew. Modern Unix systems are extremely large: the Linux kernel, for example, consists of six million lines of code.

Microkernels were an attempt to break out of the ever-growing kernels and return to a system in which most tasks would be completed by stringing together a series of smaller operations. The key problem under Unix had been trying to model the entire world as files, which no longer seemed to apply. Instead the microkernels took a step back and considered pipes as a specific example of a much more general concept: inter-process communications, or IPC. IPC could be used to emulate Unix-style pipes, but it could also be used for practically any other task, passing data at high speed between programs.

With IPC the operating system could once again be built up of a number of small programs. Networking could be removed from the kernel and placed in a separate user-space program, which would be called by other programs on the system. All hardware support would be handled in this fashion, with programs for networking, file systems, graphics, etc.

Servers are programs like any others, allowing the operating system to be modified simply by starting and stopping programs. For a small machine without networking support, for instance, the networking server simply isn't started. Under a traditional system this would require the kernel to be recompiled, something well beyond the capabilities of the average end-user. In theory the system is also more stable, because a failing server simply stops a single program, rather than causing the kernel itself to crash.

However, part of the system state is lost with the failing server, and it is generally difficult to continue execution of applications, or even of other servers with a fresh copy. For example, if a (theoretic) server responsible for TCP/IP connections is restarted, applications could be told the connection was "lost" and reconnect, going through the new instance of the server. However, other system objects, like files, do not have these convenient semantics, are supposed to be reliable, not become unavailable randomly and keep all the information written to them previously. So, database techniques like transactions, replication and checkpointing need to be used between servers in order to preserve essential state across single server restarts.

The system would look as if it had a full Unix kernel; the fact that the networking support was being "handed off" would be invisible. That system would be considerably easier to maintain: instead of a single six million-line kernel, there would be a series of smaller programs instead. Additionally, users could choose capabilities as needed and run only those programs, tailoring the system to their needs. The same sort of changes to a traditional kernel, also known as a monolithic kernel or monokernel, are very difficult due to the high level of interconnectedness between parts of the system.

The role of the kernel in such a system is limited. In addition to providing basic task management (starting and stopping other programs), it would have to provide the IPC system and provide security. When booting, the kernel would start up a series of servers to handle the hardware on the system, granting those servers additional rights as needed. New programs, those being started by the user, would use the IPC system to access hardware, calling the kernel to pass along messages after being checked for rights and validity. To handle these tasks, Mach included the concept of ports, which introduced filesystem-like endpoints into the IPC system, complete with rights for other programs to use them. For instance, a network server would hold the write permissions to the networking hardware, and keep a number of ports open for reading to allow other programs to call it. Other programs could not take over the networking hardware without the kernel specifically granting this access, and only after the networking server agreed to give up those rights.

The "collection of servers" model offered many advantages over traditional operating systems. By placing the majority of code in well-separated programs, development on such a system was considerably easier. Developing new networking stacks on a traditional monolithic kernel required the entire kernel to be recompiled and rebooted, hard-crashing the machine if there was a bug. With a microkernel there was little chance that an updated networking system would do anything other than inconvenience the user and require that one program to be relaunched. It also offered considerably more security and stability for the same reasons. Additionally the kernel itself was much smaller — later versions of Mach were only 44,000 lines of code.

Microkernels vs. monolithic kernels

Microkernels generally underperform traditional designs, sometimes dramatically. This is due in large part to the overhead of moving in and out of the kernel, a context switch, in order to move data between the various applications and servers. It was originally believed that careful tuning could reduce this overhead dramatically, but by the mid-90s most researchers had given up. In more recent times newer microkernels, designed for performance first, have addressed these problems to a very large degree. Nevertheless the market for existing operating systems is so entrenched that little work continues on microkernel design.

Examples of microkernels and OSs based on microkernels:

References

  • Exokernel a research kernel architecture with a more minimalist approach to kernel technology.


 

This software article is a stub. You can help Wikipedia by expanding it.

Retrieved from "https://en.wikipedia.org/w/index.php?title=Microkernel&oldid=42590102"