Kernel
| Kernel Designs |
|---|
| Models |
| Other Concepts |
- This article concerns itself with the theory behind kernels. There also exist several Bare bones tutorials for setting up a small working kernel.
Introduction
The kernel is the central component of an operating system. It is a natural consequence of an operating system's need to manage resources, and often the most important part of a hobby operating system. Its responsibilities include managing memory and devices and also providing an interface for software applications to use those resources. Depending on the architecture of the operating system, the kernel often manages protection of programs and multitasking.
There are a number of kernel models considered in the development of a kernel, each dependent upon personal choice and research into reliability, speed and how easily goals can be reached using the specified method. The two major models are the monolithic kernel and microkernel. The monolithic kernel is based on the idea of the kernel being a single program that sits in high memory and manages the system. At the other end of the scale, the microkernel provides as few as possible kernel mode services and negotiates the rest to user mode components.
Main Kernel Models
Monolithic Kernel
- Main article: Monolithic kernel
Monolithic kernels function with all of the kernel and device drivers inside one address space running in kernel mode. The principle advantage to this approach is efficiency (especially on x86 architectures where a task switch is a particularly expensive operation). Unfortunately, due to its single address space, a bug in a device driver can bring down the entire system.
Microkernel
- Main article: Microkernel
A microkernel tries to run most of its services and device drivers in userspace. This can result in an increase in stability and security on machines that have sufficient memory protection. In most current implementations the speed loss is considered too great to make the Microkernel practical as of yet in most commercial systems.
Subset Kernel Models
These models can usually be categorized as either of the above and usually mix concepts from both.
Hybrid Kernel
- Main article: Hybrid Kernel
The hybrid kernel, often called the macrokernel, is primarily a monolithic kernel. It differs in that the parts of it are usually segmented either in code, by a few physical modules or a mixture of both. Unlike microkernels, which use a message passing system to communicate with user space modules, hybrid kernels are usually linked together at run time and still exist as a whole in kernel space. The term is usually reserved for kernels whose core functions are modularised, not for systems who have the ability to load drivers as separate kernel modules.
Modular Kernel
- Main article: Modular Kernel
Also a monolithic model, the modular kernel, which is usually far more modular than the hybrid kernel, is based upon the same concept. The major difference is the usual ability for the kernel to load numerous unknown core modules, as opposed to simply loading in known kernel parts. It is also never considered modular because of the use of namespaces, or a simplified codebase.
Nanokernel
- Main article: Nanokernel
Often considered an incredibly minimal microkernel. The nanokernel design does not actually define the method by which parts are combined and is therefore able to sit in either camp. Most nanokernels use a message passing system to communicate with other components in order to make the the system as architecturally independent as possible. It is basically a stripped down kernel without any form of hardware abstraction, so it requires device drivers for each basic resource in the architecture. This includes devices normally controlled by a HAL, such as the Timer, RTC, PIC and DMA Controller.
Exokernel
- Main article: Exokernel
Also a tiny kernel design, the exokernel represents as little abstraction as possible, the complete opposite of the nanokernel. An exokernel is intended to give untrusted programs as much control over the hardware as possible, and in a secure way. This allows programs to take advantage of the details of present hardware instead of having to rely on the kernel to do this, which in some cases can result in drastic performance improvements. This goes however at the cost of having to write more complex software. This is quite often programmed in system libraries which provide the abstraction on the kernel's behalf.