| Microkernel |
Website Links For Microkernel |
Information AboutMicrokernel |
| CATEGORIES ABOUT MICROKERNEL | |
| operating system technology | |
| microkernels | |
|
A microkernel is a minimal Computer Operating System Kernel which, in its purest form, provides no operating-system services at all, only the ''mechanisms'' needed to implement such services, such as low-level Address Space management, Thread management, and Inter-process Communication (IPC). The microkernel is the only part of the system executing in a Kernel Mode . The actual operating-system services are provided by User-mode ''servers''. These include Device Driver s, Protocol Stack s, File System s and User-interface code. This results in a system structure that is drastically different from the more established Monolithic Kernel s. The latter traditionally have a vertically-layered structure, where applications obtain services by performing a specific System Call for each service. In contrast, a microkernel-based system features a horizontal structure, where system services are obtained by executing an IPC system call addressed to a particular server. Microkernels are closely related to Exokernel s. They also have much in common with Hypervisor s, but the latter make no claim to minimality, and are specialized to supporting Virtual Machine s. The L4 Microkernel is frequently used as a hypervisor, which indicates that a microkernel is a possible implementation of a hypervisor. The term Nanokernel is historically used to differentiate from earlier microkernels which contained actual system services, but the ''minimality'' principle used by Jochen Liedtke in the design of the L4 Microkernel implies that these terms have the same meaning; microkernel is the modern terminology. INTRODUCTION Early operating system kernels were rather small, partly because computer memory was limited. As the capability of computers grew, the number of devices the kernel had to control also grew. Early versions of UNIX had kernels of quite modest size, even though those kernels contained device drivers and file system managers. When address spaces increased from 16 to 32 bits, kernel design was no longer cramped by the hardware architecture, and kernels began to grow. (See History Of Unix ). Berkeley UNIX ( BSD ) began the era of big kernels. In addition to operating a basic system consisting of the CPU, disks and printers, BSD started adding additional File System s, a complete TCP/IP Networking System , and a number of "virtual" devices that allowed the existing programs to work invisibly over the network. This growth continued for several decades, resulting in kernels with millions of lines of Source Code . As a result of this growth, kernels were more prone to bugs and became increasingly difficult to maintain. The microkernel was designed to address the increasing growth of kernels and the difficulties that came with them. In theory, the microkernel design allows for easier management of code due to its division into User-space services. This also allows for increased security and stability resulting from the reduced amount of code running in Kernel Mode . For example, if a networking service crashed due to Buffer Overflow , only the networking service's memory would be corrupted, leaving the rest of the system still functional. On a traditional monolithic kernel, the overflow could possibly corrupt the memory of other Drivers and possibly the kernel itself, which could crash the entire system. INTER-PROCESS COMMUNICATION IPC is any mechanism which allows separate processes to communicate with each other, usually by sending Messages . This allows the operating system to be built of a number of small programs called servers, which are used by other programs on the system. Most or all support for peripheral hardware is handled in this fashion, with servers for networking, file systems, graphics, etc. With asynchronous messaging, the message sender places data on a queue. The message sender is not blocked but continues to run when sending a message, unless the queue is full. This requires buffering in the kernel, which means that messages are copied twice (sender to kernel and kernel to receiver). The Berkeley Sockets model from the UNIX world, which follows the earlier UNIX byte-stream Pipe mechanism, fits this model. POSIX adds asynchronous message queues, which queue and send discrete messages. {Link without Title} 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. As it also lends itself to more efficient implementation, modern microkernels (starting with L4 and including Minix 3 ) only provide a synchronous IPC primitive. Asynchronous IPC can be implemented on top by using helper threads. SERVERS Microkernel servers are programs like any others, except that the kernel grants some of them privileges to interact with parts of physical memory that are otherwise off limits to most programs. This allows some servers, particularly device drivers, to interact directly with hardware. A basic set of servers for a general-purpose microkernel includes file system servers, device driver servers, networking servers, display servers, and user interface device servers. This set of servers (drawn from QNX ) provides roughly the set of services offered by a monolithic UNIX kernel. The necessary servers are started at system startup and provide services, such as file, network, and device access, to ordinary application programs. With such servers running in the environment of a user application, server development is similar to ordinary application development, rather than the build-and-boot process needed for kernel development. Additionally, many "crashes" can be corrected for by simply Stopping And Restarting The Server . (In a traditional system, a crash in any of the kernel-resident code would result in the entire machine crashing, forcing a reboot). However, part of the system state is lost with the failing server, hence this approach requires applications to cope with failure. A good example is a server responsible for TCP/IP connections: If this server is restarted, applications will experience a "lost" connection, a normal occurrence in networked system. For other services, failure is less expected and may require changes to application code. For QNX, restart capability is offered as the QNX High Availability Toolkit . In order to make all servers restartable, some microkernels have concentrated on adding various Database -like techniques like Transaction s, Replication and Checkpointing in order to preserve essential state across single server restarts. An example is ChorusOS , which was targeted at high-availability applications in the Telecommunication s world. Chorus included features to allow any "properly written" server to be restarted at any time, with clients using those servers being paused while the server brought itself back into its original state. However, such kernel features are incompatible with the minimality principle, and are therefore not provided in modern microkernels, which instead rely on appropriate user-level protocols. DEVICE DRIVERS Device Drivers frequently perform Direct Memory Access (DMA), and therefore can write to arbitrary locations of physical memory, including over kernel data structures. Such drivers must therefore be trusted. It is a common misconception that this means that they must be part of the kernel. In fact, a driver is not inherently more or less trustworthy by being part of the kernel. While running a device driver in user mode does not necessarily reduce the damage a misbehaving driver can cause, in practice it is beneficial for system stability in the presence of buggy (rather than malicious) drivers: memory-access violations by the driver code itself (as opposed to the device) may still be caught by the memory-management hardware. Furthermore, many devices are not DMA-capable, their drivers can be made untrusted by running them in user mode. Recently, an increasing number of computers feature IOMMU s, many of which can be used to restrict a device's access to physical memory.2 IBM mainframes have had IO MMUs since the IBM System/360 Model 67 and System/370 . This also allows user-mode drivers to become untrusted. Historically, drivers were less of a problem, as the number of devices was small and trusted anyway, so having them in the kernel simplified the design and avoided potential performance problems. This led to the traditional driver-in-the-kernel style of UNIX, Linux, and Windows.3 With the proliferation of various kinds of peripherals, the amount of driver code escalated and in modern operating systems dominates the kernel in terms of code size. User-mode drivers predate microkernels. The Michigan Terminal System (MTS), in 1967, supported user-space drivers, the first operating system to be designed with that capability.4 ESSENTIAL COMPONENTS As a microkernel must allow building arbitrary operating-system services on top, it must provide some core functionality. At the least this includes:
This minimal design was pioneered by Brinch Hansen 's Nucleus and the hypervisor of IBM's VM . It has since been formalised in Liedtke's ''minimality principle'': Everything else can be done in a user program, although device drivers implemented as user programs may require special privileges to access I/O hardware. Policy implemented in user-level servers can be changed by replacing the servers (or letting the application chose 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 Drivers , 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. 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 key component of a microkernel is a good IPC system. 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. PERFORMANCE Obtaining a service is inherently more expensive in a microkernel-based system than a monolithic system. In the monolithic system, the service is obtained by a single system call, which requires two ''mode switches'' (changes of the processor's privilege level). In the microkernel-based system, the service is obtained by sending an IPC message to a server, and obtaining the result in another IPC message from the server. This requires two system calls (a total of four mode switches) plus two Address-space switches, as the server is typically in a different address space from the client. In addition, passing actual data to the server and back may incur extra copying overhead, while in a monolithic system the kernel can directly access the data in the client's buffers. However, Jochen Liedtke showed that Mach's performance problems were the result of poor design and implementation, and specifically Mach's excessive Cache footprint.Previously cited | |||||||||||||||||||||||||||
FURTHER READING
|
|||||||||||||||||||||||||||
|
|