微内核与Win OS解析

MACH 操作系统: MACH是由CMU（Carnegie Mellon University）于八十年代中期开始研制的一个并行分布式操作系统，其设计目标是支持松散、紧耦合多处理机体系结构(Loosely-coupled Distributed Memory Multiprocessor) ，以及多处理器与传统单机形成的网络环境
微內核 Microkernel
【解釋】：Microkernel 微內核內核提供操作系統的核心功能。

微內核是內核的精簡版本，它設計成在很小的內存空間內增加移植性，提供模塊化設計，以使用戶安裝不同的接口，如UNIX、DOS、Windows、Workplace OS、Workp1ace UNIX等。

IBM、Microaoft、開放軟件基金會(OSF)和UNIX系統實驗室(USL)等新操作系統都採用了這一研究成果的優點。

下面列出了兩種著名的微內核操作系統：
Mach Carnegie-Mellon大學設計。

Nucleus Chorus系統公司(Beaverton，oregon)設計，該公司總部設在法國。

如上所述，微內核是內核的一種精簡形式通常與內核集成在一起的系統服務層被分離出來，變成可以根據需求加入的選件，這樣就可提供更好的可擴展性和更加有效的應用環境。

使用微內核設計，對系統進行升級，只要用新模塊替換舊模塊，不需要改變整個操作系統。

我們可以用商業對比來解釋微內核的模塊概念。

考慮一個過度忙碌的商務經理。

通過將工作分給其他人，這位經理可以將他的能力更有效地用於重要的商務工作中去，並集中於其他一些任務，例如開闢新的商務分支等。

可以雇傭一些新人來支持增長的商務活動。

經理協調這些工作，但由其他的人做好雇傭他們時說好要做的事。

與此類似，微內核操作系統支持執行少量核心任務，並管理可安裝模塊的活動。

用這種方式，微內核對於它能做的工作是非常有效的，並是可移植的，這是指它可以被設計成在不同的處理器上運行。

基於微內核的操作系統如圖M-6所示進行分層，並具有如下特徵：
微內核提供一組“最基本”的服務，如進程調度、進程間通信、存儲管理、處理I/O設備。

其他服務，如檔案管理、網路支持等通過接口連到微內核。

與此相反，內核是集成的，比微內核更大。

微內核具有很好的擴展性，並可簡化應用程式開發。

用戶只運行他們需要的服務，這有利於減少磁盤空間和存儲器需求。

廠商可以很容易地將微內核移植到其他處理器平臺，並在上面增加適合其他平臺需要的模塊化部件。

(這指檔案服務器、工程應用等等)。

微內核和硬件部件有接口，並向可安裝模塊提供一個接口。

在微內核中，進程通過傳遞消息或運行“線程”來發生相互作用。

線程為將一個任務分解為多個子任務提供了途徑，在多處理器環境下，線程可以在不同的處理器上獨立運行。

下面列出一些重要的微內核操作系統：
Windows NT 這種操作系統是圍繞著Microsoft設計的微內核而設計的，它緊跟在Mach設計之後。

它提供線程調度、中斷和意外事件管理、多處理器同步和系統恢復(在掉電之後)。

它永遠不會被存儲器管理程式調出內存，而且它的執行也永遠不能被其它進程中斷。

OSF/1MK 這是開放式系統基金會的OSF/1UNIX操作系統使用微內核研究的最新版本。

它實現了Mach內核，並提供虛擬存儲管理、進程間通信和設備驅動程式管理。

UNIX SVR4 UNIX系統實驗室公司推出了一個微內核的UNIX SVR4(系統V版本4)。

它實現了Nucleus微內核。

它提供前面討論的所有微內核特徵；然而，在微內核中不管理驅動程式。

WorkPlace OS IBM的微內核是基於Mach微內核的。

這種微內核在Motorola PowerPC處理器上運行，它是Intel 80486和Pentium處理器的直接競爭者
口WorkPlace操作系統上的用戶可以選擇不同的運行於操作系統上的接口，如DOS、OS/2、Windows、U-NIX等。

IBM微內核的體積很小(約40K)，可處理基本的任務，如存儲器管理、線程管理、中斷管理和消息傳遞。

象Mach和Nucleus這樣的微內核操作系統，使用戶可以自己選擇操作系統的接口和特性。

它們十分適合可以選擇多處理器和多操作系統的變化的計算機市場，開發商也可從中受益。

它們能夠很快地從一個系統向另一個系統移植他們的產品，使最終用戶可以得到許多應用產品。

這種模塊化的設計也保證了可以得到大量的可選服務。

微内核与第二代微内核
第一代微内核
微内核的概念是由Richard Rashid在卡内基梅隆(Carnegie-Mellon)大学开发Mach操作系统时提出的，目标是建立一个基于消息传送(message passing)机制的最小内核，以便在此基础上建造对其它操作系统的模拟层来模拟其它操作系统的特性。

以Mach微内核为例，该微内核提供了进程管理、线程管理、内存管理、通信和I/O服务的功能。

在Mach微内核基础上，建立了一些运行在用户态进程中的操作系统模拟程序，用来模拟4.3 BSD、System V、HP/UX、MS-DOS等操作系统的特性。

这些模拟程序使得Mach操作系统能够支持许多运行于其它操
作系统上的应用程序，如图1所示。

所以微内核设计带来的一个重要优点是大大提高了操作系统的兼容性(compatibility) -- 使得基于微内核的操作系统能够模拟其它操作系统的特性，从而支持许多运行于其它操作系统上的运用程序。

图1. Mach微内核对其它操作系统的模拟
微内核设计带来的另外一个重要优点是提高了操作系统的扩充性(extensibility)。

微内核设计的一个目标就是内核只提供对操作系统绝对必要的功能，而把其它属于传统操作系统内核部分的功能留给用户态进程来实现。

以Mach操作系统为例，传统上属于操作系统内核功能的文件、目录服务都放在用户态进程实现了。

本质上说，微内核可以被看作是对传统操作系统共性的进一步抽象，从某种意义上说可以被称作是“操作系统的操作系统”。

这种进一步的抽象使得内核只提供机制，而把实现策略留给用户态进程-- 或者说，服务程序。

当新的硬件设备或软件技术出现时，只需要增加或修改服务程序即可，而不必象传统操作系统那样必须修改内核设计。

微内核设计的这个优点在一个最有影响力的基于微内核的操作系统-- Windows NT的发展历史上得到了充分的体现：从Windows NT的第一版(3.1)开始到最新的Windows XP，其内核的改动远远小于传统操作系统如Unix。

另外，由于微内核对操作系统作了进一步抽象，基于微内核的操作系统更容易去掉一些不必要的特性从而被剪裁成一个较小的系统。

也就是说，微内核设计使得操作系统有较好的灵活性(flexibility)。

在基于微内核的操作系统上，所有的处理器相关的代码都被封装在微内核中，从而使得操作系统有较好的移植性(portability)：因为微内核体积较小，所以移植工作也较少。

微内核系统的可靠性(reliability)也较好，这是由于体积较小的内核可以得到更多的测试。

同时，一些属于传统操作系统内核部分的功能是由服务程序实现的，所以一旦发生故障不至于导致系统的崩溃。

最后，由于微内核设计基于消息传送机制，所以能更容易支持网络通信。

第二代微内核
总的来说，微内核设计带来了良好的兼容性、扩充性、灵活性、移植性、可靠性和网络支持。

但是，微内核设计有一个重要缺点：由于微内核操作系统使用进程来隔离系统组件，这些组件之间的通信使用了消息传递方式来实现一个组件对另一个组件的调用－这实际上是进行了一次RPC（例如在NT上是LPC）调用。

但这种类似RPC的方式是通过进程间通信(IPC)机制实现的，其性能一般低于传统操作系统的系统调用的性能。

由于微内核操作系统的类似RPC调用是通过消息传送机制实现的，而传统操作系统的系统调用一般是通过类似trap的方法实现。

相比于trap方法，通过消息传送机制实现的这种类RPC调用的方式较慢－微内核完成一次这样调用的操作较慢，这是由于需要创建消息、发送消息、进程切换等更多的步骤。

这些步骤使得微内核操作系统的消息传送部分成为一个瓶颈，其性能大大低于传统操作系统的系统调用部分。

例如，在Mach 3上，一个基于消息传送机制的类RPC调用在486-DX50上引入了230µs的开销，而一个传统Unix系统的系统调用在同一硬件上仅仅引入
了20µs的开销。

这就是说，传统Unix系统的系统调用比Mach 3的类RPC调用快10倍。

这个巨大的差距明显地降低了许多运行在微内核操作系统上的应用程序的性能。

例如，Chen 和Bershad[2]在DEC-Station 5200/200上比较了应用程序在Mach和Ultrix操作系统(一个Unix变种)运行时的速度，发现相对于Ultrix操作系统Mach最多降低了这些应用程序66%的性能。

测量表明至少73%的性能下降和RPC或RPC相关活动有关[1]。

这些性能下降除了是由于消息传送机制过多的步骤引起外，还和微内核设计导致的过多用户态和核心态之间的切换以及过多的不同地址空间之间的切换有关。

一个研究表明不同地址空间之间的切换导致较高的Cache未命中率(cache-miss rate)是导致性能下降的重要原因[1]。

解决微内核设计性能问题的一个方法是扩大微内核并把一些关键的服务程序和驱动程序重新加入到内核中去，从而减少系统在用户态和核心态之间的切换以及系统在不同地址空间之间的切换。

这方面的例子有Mach操作系统和Chorus操作系统[3,4]。

另一个特别有名的例子是Windows NT 4.0的设计：这个版本的Windows NT把本来运行在用户态的图形系统又重新加入到内核中，结果大大地提高了图形系统的性能。

但是，扩大内核的方法大大削弱了微内核思想带来的优点–扩大的内核降低了系统的扩充性、灵活性和可靠性。

与扩大内核的思路相反，解决微内核性能问题的另一条思路是进一步减少内核的大小并对RPC调用进行直接优化。

这种思路导致了被称为第二代微内核的一些新的内核设计的出现。

在这些新的微内核中，L4微内核是一个著名的例子。

L4微内核
L4微内核的核心功能是支持一个基于消息传送的IPC原语，以便在此基础上实现高性能的RPC机制。

在486-DX50上，L4实现了一个RPC调用开销仅用10µs的性能。

相比之下，在Mach操作系统上一个RPC的调用开销为230µs，而在Unix上一个RPC的调用开销为20µs。

也就是说，L4的IPC比第一代微内核的IPC快20倍以上，甚至比传统操作系统的IPC 还要快。

除此之外，L4微内核还提供了地址空间管理原语和线程管理原语。

L4的地址空间管理原语负责内存地址空间的映射，支持三个操作：Grant、Map和Flush。

基于这些操作，L4可以支持由不同的用户进程以不同的策略来映射页面。

L4的线程管理原语使得线程调度能够由用户进程以不同的策略来实现，从而支持用户态的线程调度器。

由于L4微内核仅仅以7个系统调用接口就实现了以上功能，所以只占用了12K内存[1]。

相比之下，一个典型的第一代微内核占用300K内存以支持140个系统调用接口[1]。

L4微内核的另一个特点在于它的中断处理方式：L4微内核把硬件中断处理成IPC消息。

微内核把硬件当作是一些能够发送IPC消息给相关处理代码的线程，而把中断服务程序当作是一些正在接收这些IPC消息的线程。

当一个硬件中断发生时，微内核会为这个中断产生一条消息并把此消息发送到和此中断相关联的用户进程中，然后由用户进程中的负责接收这条IPC消息的线程来处理这个硬件中断。

这样，内核只负责产生中断消息，而不用涉及到具体的中断处理，从而使得中断处理的具体策略和内核隔离开来。

这种处理方式使得设备驱动程序可以运行在用户态，其中断服务代码的大体结构如下：
driver thread:
do
wait for (msg, sender);
if sender = my_hardware_interrupt
then read/write I/O ports;
reset hardware interrupt
else…
endif
enddo
其它第二代微内核级的设计
Exokernel微内核
相对于L4微内核，Exokernel微内核是一个更加激进的设计。

Exokernel微内核的核心观点是：只要内核还提供对系统资源的抽象，就不能实现性能的最大优化-- 内核应该支持一个最小的、高度优化的原语集，而不是提供对系统资源的抽象。

从这个观点上来说，IPC也是一个太高级的抽象因而不能达到最高的性能。

Exokernel微内核的核心是支持一个高度优化的原语名叫保护控制转移(protected control transfer, PCT)。

PCT是一个不带参数的跨地址空间的过程调用，其功能类似于一个硬件中断。

在PCT的基础上，可以实现高级的IPC抽象如RPC。

在MIPS R3000处理器上，一个基于PCT的RPC实现了仅10µs的开销，而在同一硬件上运行的Mach RPC为95µs[1]。

Rambler内核
Rambler操作系统不同于传统操作系统：它没有传统操作系统的严格意义上的内核。

如果一定要定义一个内核的话，它的IPC/HAL模块就扮演着传统内核的角色，可以被系统几乎所有的部分调用。

系统核心通过支持跨地址空间和跨计算机的远程方法调用，在全系统的各个部分架起了一座桥梁。

在Rambler系统中，所有的远程调用都是通过OCP协议进行的。

在Rambler操作系统中也有一个内核态进程，但和传统操作系统的内核有很大不同的：Rambler的内核进程只是一个运行在内核态的地址空间。

在这个内核态地址空间中有什么系统部件，是不可预知的，取决于处理器的体系结构。

在目前的80386的实现上，内核进程包含了中断管理器、地址空间管理器、8237A DMA控制器驱动模块、OCP根地址空间和一些系统的启动代码。

但这些部件的位置随时可以因系统的实现策略和处理器体系结构的需要而改变。

例如在其它处理器平台上，地址空间管理器可能被放在一个特定的用户态地址空间中，而不必运行在内核态。

又如，在Rambler后继版本的实现中，OCP根地址空间可能会放在在用户态地址空间中，而启动代码会被抛弃。

所以，Rambler内核进程实际不同于传统操作系统的内核。

而传统操作系统内核的主要功能被Rambler系统的各个子系统代替了。

如：进程管理被地址空间管理器(可能运行在用户态)所替代；进程切换被IPC模块的调用切换所代替；线程管理由IPC/HAL模块和应用程序运行环境所替代；IPC模块的一部分是运行在用户态的；虚拟内存系统可以作为运行在用户态的系统服务，甚至嵌入到应用程序中作为私有的External Pager；设备驱动程序一般运行在用户态地址空间中；存储系统（包括传统文件系统）运行在用户态地址空间甚至嵌入到应用程序中。

因而从某种意义上说，Rambler 操作系统可以被认为是一种无核设计。

文献引用
1. 1.Jochen Liedtke, Towards Real Microkernels. Communications of the ACM,
39(9):70--77, September 1996.
2. 2.Chen, J.B. and Bershad, B.N. The impact of operating system structure on memory
system performance. In Proceedings of the 14th ACM Symposium on Operating System Principles (SOSP) (Asheville, N.C., Dec. 1993). ACM Press, 1993, pp. 120–133.
3. 3.Bricker, A., Gien, M., Guillemont, M., Lipkis, J., Orr, D., and Rozier, M. A new look at
microkernel-based Unix operating systems. Tech. Rep. CS/TR-91-7, Chorus systèmes, Paris, France, 1991.
4. 4.Condict, M., Bolinger D., McManus, E., Mitchell, D., and Lewontin, S. Microkernel
modularity with integrated kernel performance. Tech. Rep., OSF Research Institute, Cambridge, Mass, 1994.
我又一次发现自己真的要感谢David Solomon和Mark Russinovich了，他们提供了机会让我在他们合著的关于Windows内部机理的系列图书的最新版本中写一些话。

在这一系列图书中，上一版本的出版距新版本已经有三年了，在此期间Windows已经有了两个主要的发行版本：一个是对客户系统的重大更新，另一个则是对刚刚准备就绪要发行的服务器系统的重大更新。

对于像这样一本书的作者，他们面临的两个日益显著的问题是，跟踪Microsoft Wi ndows NT系统在实现方面的进展，以及记录下在每一个版本中哪些特性的实现发生的变化。

最终，本书的作者们完成了这一杰出的工作，为全书提供了例子和解释。

当我第一次碰到David Solomon时，我还在DEC（Digital Equipment Corporation）为VAX的VMS操作系统工作，当时他只有16岁。

从那时起，他一直涉足于操作系统的开发和对操作系统内部机理的教学。

我认识Mark Russinovich的时间要短一些，但知晓他在操作系统领域的专业特长也很有一段时间了。

他曾经做出了很杰出的工作，比如可在Microsoft Windows 98上运行的NTFS文件系统，以及他的“实时”Windows内核调试器（通过该工具可以在Windows系统运行的时候探查其内部状态）。

Windows NT项目最初是从1988年10月份开始的，起初的目标是实现一个可移植的系统，能够解决OS/2兼容性、安全性、POSIX、多处理能力、集成的网络功能，以及可靠性等诸多问题。

随着Windows 3.0的发行和巨大成功，这些系统目标很快也随之发生变化，变成了直接处理Windows的兼容性，而把OS/2兼容性移到一个子系统中。

我们最初认为，可以在两年多时间内完成第一个Windows NT系统。

实际上，第一个发行版本花了四年半时间，到1993年夏天才完成，这一发行版本支持Intel i386、In tel i486和MIPS R4000处理器。

六周以后，我们也引入了对于Digital Alpha处理器的支持。

Windows NT的第一个发行版本比预期的要大、要慢，所以，下一个重要的阶段是一个称为Daytona的项目（用Florida的一条高速公路来命名）。

这一发行版本的主要目标是减小系统的尺寸，提高系统的速度，当然，也要使它更加可靠。

1994年秋天我们发
布了Windows NT 3.5，过了6个月，又发布了Windows NT 3.51，此更新版本包含了对于IBM PowerPC处理器的支持。

Windows NT下一个版本的目标是，更新用户界面以便与Windows 95兼容，以及将M icrosoft已经开发多年的各种Cairo技术融合进来。

这一系统的开发花了两年多时间，最终在1996年夏天作为Windows NT 4.0面市。

NT的下一个版本是Windows 2000，这是最后一个客户和服务器系统同时发布的系统。

这一版本建立在与以前版本相同的Windows NT技术基础之上，同时也引入了一些重要的新特性，比如活动目录。

花了三年半时间来开发Windows 2000，对当时的Windo ws NT技术作了全面的测试和调节。

开发Windows 2000是过去11年来跨越4种体系结构的系统开发之巅峰。

在Windows 2000开发结束时，我们又启动了一个宏伟计划，要在新的客户和服务器系统中融入新的、增强的客户特性和改进的服务器能力。

在这一计划实施过程中，有一点越来越清楚，即服务器特性的实现将会导致客户特性实现的滞后，因此，客户和服务器系统的版本被分开了。

在2001年8月，Windows XP Professional和Windows XP Ho me Edition发布了，一年多以后，在2003年3月，Microsoft Windows Server 2003也发布了。

除了对Intel x86体系结构的支持以外，这些系统还包含了对于Intel IA-64的支持，这标志着Windows NT第一次进入了64位处理的领域。

本书是有关Windows XP和Windows Server 2003的内部结构和工作机理的一部权威之作。

而且，它也提供了Windows将来转移到64位计算上的大略介绍，包括AMD在20 03年引入的x64体系结构（AMD64）和Intel于2004年2月份宣称的64位支持（EM64 T）。

完全支持x64的客户和服务器版本计划在2005年上半年发行，本书包含了有关x 64系统实现细节的诸多精辟观点。

当x86体系结构开始显现出旧时代征兆之时，x64体系结构即是Windows NT的新时代的开始。

这一体系结构提供了32位x86兼容性，以保护过去的软件投资，同时它也提供了64位寻址能力以便满足新应用程序更大的空间需求。

这既保护了32位软件的投资，同时也为Windows NT进入下一个10年或走得更远而提供了必不可少的支撑。

尽管在过去几年中，Windows NT系统经历了几次名称上的变化，但是，它仍然完全建立在最初的Windows NT代码基（code base）的基础之上。

随着时间的推移和各种发明创造的诞生，许多内部特性的实现发生了重大的变化。

本书作者已经做了令人赞不绝口的工作来诠释Windows NT代码基的细节，及其在不同版本之间和不同平台之间的实现上的差异，同时他们也开发了一些例子和工具来帮助读者理解Windows NT内部是如何工作的。

每一个认真的操作系统开发人员都应该在自己的案头有这本书。

David N. Cutler
现在我们已经了解了必须熟悉的术语、概念和工具，所以，我们准备开始挖掘Micr osoft Windows操作系统的内部设计目标和数据结构。

这一章讲述系统的总体结构——关键的部件、它们相互之间如何交互，以及它们分别运行在什么样的环境下。

为了提供一个有助于理解Windows内部机理的框架，首先回顾一下最初的需求和设计目标，这些需求和目标基本上勾画出了Windows系统最初的设计和规范。

2.1 需求和设计目标
回到1989年，下面的需求导致了Windows NT的以下规范：
n 提供一个真正32位的、抢先式的（preemptive）、可重入的（reentrant）虚拟内存操作系统；
n 在多种硬件体系结构和平台上运行；
n 可在对称多处理器系统（symmetric multiprocessing systems）上运行，并且能很好地适应处理器的数量；
n 成为一个主要的分布式计算平台，无论是作为网络客户还是服务器；
n 能够运行大多数已有的16位MS-DOS和Microsoft Windows 3.1应用程序；
n 符合政府对于POSIX 1003.1兼容性的要求；
n 符合政府和工业界对于操作系统安全性方面的要求；
n 支持Unicode，以便很容易地适应全球市场。

要创建一个满足这些需求的系统，必须做出数千个决定；为了便于做出这些决定，W indows NT设计小组在项目开始之初选择了下面的设计目标：
n 扩展性（Extensibility）编写的系统代码必须能够随着市场需求的变化而自如地增长和改变；
n 可移植性（Portability）系统必须能运行在多种硬件体系结构上，必须能根据市场的需要，相对容易地移到新的体系结构上；
n 可靠性和健壮性（Reliability and Robustness）系统应该能够保护自己，不会因内部的错误和外部的篡改而不能工作。

应用程序应该无法伤害操作系统或者其他的应用程序；
n 兼容性（Compatibility）虽然Windows NT应该扩展已有的技术，但是它的用户
界面和API应该与老版本的Windows和MS-DOS兼容。

而且它也应该能与其他的系统，
比如UNIX、OS/2和NetWare，很好地互操作；
n 性能（Performance）在其他设计目标的约束下，系统在每一种硬件平台上应尽可
能运行得更快，对外部的响应尽可能地及时。

随着我们挖掘Windows内部结构和内部操作的各种细节，你将会看到，这些原始的
设计目标和市场要求是如何成功地融入到系统的构造过程中的。

但是，在我们开始挖掘
内部细节之前，先来看一下Windows的总体设计模型，并且将它与其他的现代操作系统
作一比较。

在大多数多用户操作系统中，应用程序与操作系统本身是隔离的——操作系统内核代码运行在处理器的特权模式下（在本书中称为内核模式，kernel mode），可以访问系统数据和硬件；应用程序代码运行在处理器的非特权模式下（称为用户模式，user mode），只有很有限的一组接口可以使用，对系统数据的访问受到限制，并且无法直接访问硬件。

当用户模式程序调用一个系统服务时，处理器捕获到该调用，然后将调用线程切换到内核模式。

当该系统服务完成时，操作系统将线程环境切换回用户模式，并允许调用者继续执行。

与大多数UNIX系统类似，Windows是一个庞大而完整的操作系统；操作系统的大部分代码与设备驱动程序代码共享同样的受保护的内核模式内存空间。

这意味着，操作系统的任一组件或者设备驱动程序都有可能破坏其他系统组件所使用的数据。

Windows是一个微内核系统吗
尽管有些人如此声称，但是按照微内核（microkernel）的典型定义，Windows并不是一个微内核系统。

在微内核的定义中，操作系统的主要组件（比如内存管理器、进程管理器和I/O 管理器）运行在各自独立的进程中，它们有自己私有的地址空间，在这一组组件之上是微内核提供的一组原语服务。

例如，CMU（Carnegie Mellon University，卡耐基·梅隆大学）的Mach操作系统是一个现代的微内核体系结构的例子，它实现了一个最小的内核，包括线程调度、消息传递、虚拟内存和设备驱动程序。

任何其他的组件，包括各种API、文件系统和网络等，都运行在用户模式下。

然而，Mach微内核操作系统的商业版本实现，往往至少将所有的文件系统、网络和内存管理代码放在内核模式中运行。

原因很简单：纯粹的微内核设计在商业上是不切实际的，因为它的效率太低。

那么，Windows中有那么多代码运行在内核模式下，是否就意味着它比一个真正的微内核操作系统一定更加容易崩溃呢？并非如此。

请考虑下面的情景。

假设在操作系统的文件系统代码中有一个错误，该错误会导致文件系统时不时地崩溃。

在一个传统的操作系统中，内核模。