|
|
发表于 2003-5-4 23:40:54
|
显示全部楼层
The kernel is the fundamental part of an operating system. It is responsible for providing secure multiplexing and arbitration of a machine's hardware, which it provides in the form of a set of abstractions.
Some operating systems, such as Linux, have monolithic kernels which provide rich and powerful abstractions. Others, such as Windows XP, Mac OS X, and GNU Hurd have microkernels which provide a small set of simple abstractions. Yet others have exokernels which provide no abstractions. In the latter cases, the remaining features require small modules which can be flexibly configured.
Monolithic kernels
The monolithic approach definines a high-level virtual interface over the hardware, with a set of primitives or system calls to implement operating system services such as process management, concurrency, and memory management in several modules that run in supervisor mode.
Even if every module servicing these operations is separate from the whole, the code integration is very tight and difficult to do easily and correctly, and, as all the modules run in the same space, a bug in one of them can bring down the whole system. However, when the implementation is complete and trustworthy, the tight internal integration of components allows the low-level features of the underlying system to be effectively exploited, making a good monolithic kernel highly efficient. Proponents of the monolithic kernel approach make the case that if code is not correct, it does not belong in a kernel, and if it is, there is little advantage in the microkernel approach.
Examples of monolithic kernels:
* Traditional UNIX kernels, including the Linux kernel
Microkernels
The microkernel approach consists in defining a very simple virtual machine over the hardware, with a set of primitives or system calls to implement minimal OS services as thread management, address spaces and interprocess communication.
The main objective is the separation of basic service implementations from the operation policy of the system. For example, the process I/O locking could be implemented by a user server running on top of the microkernel. These user servers, used to carry on the system high level parts, are very modular and simplify the structure and design of the kernel. A service server that fails doesn't bring the entire system down; this simpler module can be restarted independently of the rest.
Examples of microkernels:
* The Mach operating system
* The Darwin kernel for Mac OS X, a variant of Mach.
* The L4 microkernel family
* QNX
* BeOS
* AIX
* Windows NT
Monolithic kernels vs. microkernels
A monolithic kernel is much faster than a microkernel, though a microkernel can dynamically load and unload modules as needed to reduce resource usage.
In the early 1990s, monolithic kernels were considered obsolete. The design of Linux as a monolithic kernel rather than a microkernel was the topic of a famous flame war between Linus Torvalds and Andrew Tanenbaum. A summary of which can be found at http://www.dina.dk/~abraham/Linus_vs_Tanenbaum.html
However, microkernels have been found to have a number of issues which have prevented them from displacing monolithic kernels. It appears that traditional microkernels like Mach are much slower and less responsive than monolithic kernels. The best explanation for this is that optimal performance of a kernel depends on coordination between different kernel subsystems, and a microkernel architecture limits the ability to transfer information between these subsystems.
Also, the benefits of a microkernel architecture have so far been less than orginally forseen. The main claim in favor of microkernels was that by separating functions, the code would be more maintainable and understandable. However, some claim that the amount of effort in maintaining any kernel code is sufficiently high that the improvements in maintainablity generated by a microkernel architecture are marginal.
Exokernels
Exokernels are a rather radical approach to OS design. The central line of thought is, "separate protection from management".
The idea behind this is, nobody knows better how to make efficient use of available hardware but the application developer, so enable him to make the decisions. Exokernels are extremly small, since they arbitrarily limit their functionality to the protection and multiplexing of resources.
"Classic" kernel designs (both monolithic and microkernels) abstract the hardware, hiding resources under the hardware abstraction layer (HAL), or behind "trusted" servers (i.e., the servers are extensions of kernel functionality, and there is no way around them).
In these "classic" systems, if you allocate memory, you have no saying in which physical page you will be returned by the OS. If you write to a file, you have no saying on file system or physical block allocation.
It is this abstraction layer that an exokernel tries to avoid. It allows an application to request a specific piece of memory, a specific disk block etc., and merely ensures that the requested resource is free, and the application is allowed to access it.
Since an exokernel is therefore only providing a very low-level interface to the hardware, lacking any of the higher-level functionalities of other operating systems, it is augmented by a "library operating system". Such a libOS interfaces to the exokernel below, and provides application writers with the familiar functionalities of a complete OS.
This has several implications:
It is possible to have several different libOSes in the system. If, for example, you have a libOS that exports a Unix API and one exporting a Windows API, nothing keeps you from running an application linking the Windows libOS and one linking the Unix libOS, simultaneously. libOS development is done in user space - no reboots, no terminal debugging, fully memory protected. Application designers are free to replace parts, or all of the libOS with abstractions of their own, to increase performance. |
|
IP卡
狗仔卡
提升卡
置顶卡
沉默卡
喧嚣卡
变色卡
显身卡
发表于 2003-5-4 16:39:15
