此而增加的内核设计的灵活性和可维护性可以弥补任何损失 。
我并不想讨论这些问题，但必须说明非常有趣的一点是，这种争论经常会令人想到前几年
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的众多特点仍然值得移植，新的移植版本就会不断涌现 。
推荐阅读
- 鸟的住处叫什么名称
- 铁路12306中转人工服务的简单步骤
- 大学毕业后档案是怎么处理的呀
- 诺基亚x71详细激活步骤介绍
- 压力的作用效果与什么有关
- 其它 Linux 常用命令
- oppor15中开启省电模式的操作步骤
- 我的世界如何合成合金
- 消防桶为什么是半圆的
- 美的热水器怎么排水