Linux操作系统架构简介可以说, Linux是21世纪初最火的操作系统。注意,我只在这时说它是最“火”的,而不是最“好”的。最好的定义对于每个人都不一样,为避免产生口水仗,我不在书中对 Linux进行评价。不过我得先介绍一下 Linux的架构。Linux肯定是一款大内核操作系统, Linus Tovals和 Tanenbaum的网上争论余音绕梁,相信知道此事的读者一定还记得 Linus支持大内核的建议吧。虽然说 Linux是以大内核的方式运行,但编译方式已经吸收了 Windows的动态加载模块的特点。也就是说,彼时(80s)的大内核和现在说的大内核不完全是概念。那时候的大内核,不仅运行的时候所有驱动、文件系统、包括本书要讨论的协议栈要运行在内核态,而且编译的时候,编译的文件必须同时被编译到一个大的二进制文件中。如今的内核,在编译的时候,可以有选择的加入或减去某部分代码,使其编译出来的内核变“小”,而一些驱动程序和模块可以在系统起来以后再加载。那么就单纯的那个内核镜像而言,真的还不算“大”,这个时候要说 Linux是大还是小还真有点难。

   操作系统内核可能是微内核,也可能是大内核(后者有时称之为宏内核 Macrokernel)。按照类似封装的形式,这些术语定义如下

微内核( Microkernel kernel)—一在微内核中,大部分内核都作为独立的进程在特权状态下运行,它们通过消息传递进行通讯。在典型情况下,毎个概念模块都有一个进程。因此,如釆在设计中有一个系统调用模块,那么就必然有一个相应的进程来接收系统调用,并和能够执行系统调用的其它进程(或模块)通讯以完成所需任务。在这些设计中,微内核部分经常只不过是一个消息转发站:当系统调用模块要给文件系统模抉发送消息时,消息直接通过内核转发。这种方式有助于实现模块间的隔离。(某些时候,模块也可以直接给其它模块传递消息。)在一些微内核的设计中,更多的功能,如IO等,也都被封装在内核中了。但是最根本的思想还是要保持微内核尽量小,这样只需要把微内核本身进行移植就可以完成将整个内核移植到新的平台上。其它模抉都只依赖于微内核或其它模块,并不直接直接依赖硬件。微内核设计的一个优点是在不影响系统其它部分的情况下,用更高效的实现代替现有文件系统模块的工作将会更加容易。我们甚至可以在系统运行时将开发岀的新系统模抉或者需要替换现有模抉的模块直接而且迅速的加入系统。另外一个优点是不需要的模块将不会被加载到内存中,因此微内核就可以更有效的利用内存。

大内核( Monolithic kernel)—一单内核是一个很大的进程。它的内部又可以被分为若干模块(或者是层次或其它)。但是在运行的时候,它是一个独立的二进制大映象。其模块间的通讯是通过直接调用其它模块中的函数实现的,而不是消息传递。单内核的支持者声称微内核的消息传递开销引起了效率的损失。微内核的支持者则认为因此而增加的内核设计的灵活性和可维护性可以弥补任何损失。就像 Linux内核是微内核和单一内核的混合产物样。 Linux内核基本上是单一的,但是它并不是一个纯粹的集成内核。为什么 Linux必然是单内核的呢?个方面是历史的原因:在 Linus的观点看来,通过把内核以单一的方式进行组织并在最初始的空间中运行是相当容易的事情。这种决策避免了有关消息传递体系结枃,计算模块装载方式等方面的相关工作。(内核模块系统在随后的几年中又进行了不断地改进。)如果 Linux是纯微内核设计,那么向其它体系结构上的移植将会比较容易。实际的情况是,Iiux内核的移植虽然不是很简单,但也绝不是不可能的。虽然这比微内核的移植需要更多的代码,但是Liux的支持者将会提出,这样的 Linux内核移植版本比微内核更能够有效的利用底层硬件,因而移植过程中的额外工作是能够从系统性能的提高上得到补偿的。这种特殊设计的权衡也不是很轻松就可以达到的,单内核的实现策略公然违背了传统的看法,后者认为微内核是未来发展的趋势。但是由于单一模式(大部分情况下)在 Linux中运行状态良好,而且内核移植相对来说比较困难,但没有明显地阻碍程序员团体的工作,他们已经热情高涨地把内核成功的移植到了现存的大部分实际系统中,更不用说类似掌上型电脑的一些看起来很不实际的目标了。只要 Linux的众多特点仍然值得移植,新的移植版本就会不断涌现。