什么是微内核?

cnhnln

以前常听人攻击linux说它不是微内核,究竟什么是微内核?微内核有何好处?UNIX,win9x和winnt是微内核吗?如何判断是不是微内核?

jackyhong

下面是我摘录《linux内核注释》的一部分：

Linux大部分都是单内核的
操作系统内核可能是微内核，也可能是单内核（后者有时称之为宏内核Macrokernel）。按照类似封装的形式，这些术语定义如下：

l         微内核（Microkernel kernel）――在微内核中，大部分内核都作为独立的进程在特权状态下运行，它们通过消息传递进行通讯。在典型情况下，每个概念模块都有一个进程。因此，如果在设计中有一个系统调用模块，那么就必然有一个相应的进程来接收系统调用，并和能够执行系统调用的其它进程（或模块）通讯以完成所需任务。

在这些设计中，微内核部分经常只不过是一个消息转发站：当系统调用模块要给文件系统模块发送消息时，消息直接通过内核转发。这种方式有助于实现模块间的隔离。（某些时候，模块也可以直接给其它模块传递消息。）在一些微内核的设计中，更多的功能，如I/O等，也都被封装在内核中了。但是最根本的思想还是要保持微内核尽量小，这样只需要把微内核本身进行移植就可以完成将整个内核移植到新的平台上。其它模块都只依赖于微内核或其它模块，并不直接直接依赖硬件。

微内核设计的一个优点是在不影响系统其它部分的情况下，用更高效的实现代替现有文件系统模块的工作将会更加容易。我们甚至可以在系统运行时将开发出的新系统模块或者需要替换现有模块的模块直接而且迅速的加入系统。另外一个优点是不需要的模块将不会被加载到内存中，因此微内核就可以更有效的利用内存。

l         单内核（Monolithic kernel）――单内核是一个很大的进程。它的内部又可以被分为若干模块（或者是层次或其它）。但是在运行的时候，它是一个独立的二进制大映象。其模块间的通讯是通过直接调用其它模块中的函数实现的，而不是消息传递。

单内核的支持者声称微内核的消息传递开销引起了效率的损失。微内核的支持者则认为因此而增加的内核设计的灵活性和可维护性可以弥补任何损失。

我并不想讨论这些问题，但必须说明非常有趣的一点是，这种争论经常会令人想到前几年CPU领域中RISC和CISC的斗争。现代的成功CPU设计中包含了所有这两种技术，就像Linux内核是微内核和单一内核的混合产物一样。Linux内核基本上是单一的，但是它并不是一个纯粹的集成内核。前面一章所介绍的内核模块系统将微内核的许多优点引入到Linux的单内核设计中。（顺便提一下，我考虑过一种有趣的情况，就是Linux的内核模块系统可以将系统内核转化成为简单的不传递消息的微内核设计。虽然我并不赞成，但是它仍然是一个有趣的想法。）

为什么Linux必然是单内核的呢？一个方面是历史的原因：在Linus的观点看来，通过把内核以单一的方式进行组织并在最初始的空间中运行是相当容易的事情。这种决策避免了有关消息传递体系结构，计算模块装载方式等方面的相关工作。（内核模块系统在随后的几年中又进行了不断地改进。）

另外一个原因是充足的开发时间的结果。Linux既没有开发时间的限制，也没有深受市场压力的发行进度。 所有的限制只有并不过分的对内核的修改与扩充。内核的单一设计在内部实现了充分的模块化，在这种条件下的修改或增加都并不怎么困难。而且问题还在于没有必要为了追求尚未证实的可维护性的微小增长而重写Linux的内核。（Linus曾多次特别强调了如下的观点：为了这点利益而损耗速度是不值得的。）后面章节中的部分内容将详细的重新考虑充足开发时间的效果。

如果Linux是纯微内核设计，那么向其它体系结构上的移植将会比较容易。实际上，有一些微内核，如Mach微内核，就已经成功的证明了这种可移植性的优点。实际的情况是，Linux内核的移植虽然不是很简单，但也绝不是不可能的：大约的数字是，向一个全新的体系结构上的典型的移植工作需要30,000到60,000行代码，再加上不到20,000行的驱动程序代码。（并不是所有的移植都需要新的驱动程序代码。）粗略的计算一下，我估计一个典型的移植平均需要50,000行代码。这对于一个程序员或者最多一个程序小组来说是力所能及的，可以在一年之内完成。虽然这比微内核的移植需要更多的代码，但是Linux的支持者将会提出，这样的Linux内核移植版本比微内核更能够有效的利用底层硬件，因而移植过程中的额外工作是能够从系统性能的提高上得到补偿的。

这种特殊设计的权衡也不是很轻松就可以达到的，单内核的实现策略公然违背了传统的看法，后者认为微内核是未来发展的趋势。但是由于单一模式（大部分情况下）在Linux中运行状态良好，而且内核移植相对来说比较困难，但没有明显地阻碍程序员团体的工作，他们已经热情高涨地把内核成功的移植到了现存的大部分实际系统中，更不用说类似掌上型电脑的一些看起来很不实际的目标了。只要Linux的众多特点仍然值得移植，新的移植版本就会不断涌现。

cnhnln

微内核与巨内核之争

Linux以一种难以置信的速度流行起来。在它高速发展的历程中，不能不提到著名的Linux是否过时之争。双方当事人恰恰就是Linus和Minix的作者Andy Tanenbaum教授。在这次争论中，双方对操作系统的很多方面都进行了深入的讨论，至今看来仍然很有意义。

最先发难的是Andy Tanenbaum教授。1992年1月29日，他在题为“Linux is obsolete”的E-mail中说到了对未来一段时间内操作系统发展的观点。

（1）是微内核还是巨内核

传统的操作系统使用的都是巨内核结构。这意味着操作系统是一个整体可执行文件，进程管理、内存管理和文件系统全部运行在内核模块中。而目前较新的一种设计方式是微内核，操作系统的大多数部分作为独立的进程运行，存在于内核以外，内核通过消息传递、中断处理、低级进程管理，以至于I/O来完成各种工作。

他认为微内核明显优于巨内核，而Linux使用的恰恰就是巨内核。Andy Tanenbaum教授认为这是历史的倒退，相当于在20世纪90年代仍然使用70年代的技术。

（2）灵活性(Portability)

Andy Tanenbaum教授还认为，不应该对于一种特定的体系机构编写操作系统，因为体系结构的进化是非常快的，这样将导致移植非常困难。目前的Linux过于依赖80386架构，而这样显然是不对的。

之后Linus在回复的邮件中承认，微内核的确好一些，至少在理论上是这样。但是Linus认为在当时拥有一个可用的操作系统更加重要。他说，如果前一年的春天GNU的内核Hurd推出的话，那Linux就没有存在的必要了。Linus认为，不能仅仅用是否是微内核作为评论操作系统优秀与否的标准。

Linus说的是很重要的一点。微内核模式在开发和调试上都带来了一定的难度，这也许是Hurd迟迟不能推出的一个重要原因。在很久以后的Revolution OS记录片中，GNU的主教Richard Stallman承认，Hurd各部分之间的配合和调试是个大问题。也许Linus的确有远见。他认为应该迅速推出能用的系统，而不是在做了最优化设计之后再推出系统，这个观点值得我们深思。

对于灵活性，Linus认为只是某些不愿意写新程序的人的借口。他认为事实上由于POSIX标准的缘故，Linux比Minix更具灵活性，因为往Linux上移植程序会更加方便。灵活性是一个好主意，但是过犹不及，OS应该最大限度地利用架构的特点，这样会让开发变得更加容易。

后来双方又进行了很多争论，涉及到不少技术细节，也有不少别的人参与进来，他们说的话对于想学习OS的人很有启发意义。

今天的Linux已经不能简单地说是一个微内核系统或巨内核系统了，它同时具有这两种系统的不同特点。不过我们可以看到，正是像上面这样的讨论，构成了今天这一庞大的OS理论基础，这也正是Linux自由、开放的精神所在。