Linux大部分都是单内核的服务器
操做系统内核多是微内核,也多是单内核(后者有时称之为宏内核Macrokernel)。按照相似封装的形式,这些术语定义以下:
微内核(Microkernelkernel)――在微内核中,大部份内核都做为单独的进程在特权状态下运行,他们经过消息传递进行通信。在典型状况下,每一个概念模块都有一个进程。所以,假如在设计中有一个系统调用模块,那么就必然有一个相应的进程来接收系统调用,并和可以执行系统调用的其余进程(或模块)通信以完成所需任务。
在这些设计中,微内核部分常常只可是是个消息转发站:当系统调用模块要给文档系统模块发送消息时,消息直接经过内核转发。这种方式有助于实现模块间的隔离。(某些时候,模块也可以直接给其余模块传递消息。)在一些微内核的设计中,更多的功能,如I/O等,也都被封装在内核中了。可是最根本的思想仍是要保持微内核尽可能小,这样只须要把微内核自己进行移植就可以完成将整个内核移植到新的平台上。其余模块都只依赖于微内核或其余模块,并不直接直接依赖硬件。
微内核设计的一个长处是在不影响系统其余部分的状况下,用更高效的实现代替现有文档系统模块的工做将会更加容易。咱们甚至可以在系统运行时将研发出的新系统模块或须要替换现有模块的模块直接并且迅速的加入系统。另一个长处是无需的模块将不会被加载到内存中,所以微内核就可以更有效的利用内存。
单内核(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的众多特色仍然值得移植,新的移植版本就会不断涌现。多线程
另外一篇文字
Linux内核和传统Unix内核的比较
来源: 未知
全部的Unix内核都同宗同源,而且提供相同的API,现代的Unix内核存在许多设计上的类似之处。Unix内核几乎毫无例外的都是一个不可分割的静态可执行块(文件)。也就是说,它们必须以完整、单独的可执行块的形式在一个单独的地址空间中运行。
Unix内核几乎都须要硬件系统提供页机制以管理内存。这种页机制能够增强内存空间的保护,并保证每一个进程均可以运行于不一样的虚地址空间上。
单内核与微内核设计之比较
操做系统内核能够分为两大设计阵营:单内核和微内核(第三阵营外内核,主要用在科研系统中,但也逐渐在现实世界中壮大起来)。模块化
单内核是两大阵营中一种较为简单的设计,在1980年以前,全部的内核都设计成单内核。所谓单内核就是把它从总体上做为一个单独的大过程来实现,并同时运行在一个单独的地址空间。所以,这样的内核一般以单个静态二进制文件的形式存放于磁盘。全部内核服务都在这样的一个大内核空间中运行。内核之间的通讯是微不足道的,由于你们都运行在内核态,并身处同一地址空间:内核能够直接调用函数,这与用户空间没有什么区别。这种模式的支持者认为单模块具备简单和高性能的特色。大多数Unix系统都设计为单模块。
另外一方面,微内核并不做为一个单独的大过程来实现。相反,微内核的功能被划分为独立的过程,每一个过程叫作一个服务器。理想状况下,只有强烈请求特权服务的服务器才运行在特权模式下,其余服务器都运行在用户空间。不过,全部的服务器都保持独立并运行在各自的地址空间。所以,就不可能像单模块内核那样直接调用函数,而是经过消息传递处理微内核通讯:系统采用了进程间通讯(IPC)机制,所以,各类服务器之间经过IPC机制互通消息,互换“服务”。服务器的各自独立有效地避免了一个服务器的失效祸及另外一个。
一样,模块化的系统容许一个服务器为了另外一个服务器而换出。由于IPC机制的开销比函数调用多,又由于会涉及内核空间到用户空间的上下文切换,所以,消息传递须要必定的周期,而单内核中简单的函数调用没有这些开销。基于此,付之于实际的微内核系统让大部分或所有服务器位于内核,这样,就能够直接调用函数,消除频繁的上下文切换。Windows NT内核和Mach(Mac OS X的组成部分)是微内核的典型实例。无论是Windows NT仍是MacOS X,都在其新近版本中不让任何微内核服务器运行在用户空间,这违背了微内核设计的初衷。
Linux是一个单内核,也就是说,Linux内核运行在单独的内核地址空间。不过,Linux汲取了微内核的精华:其引觉得豪的是模块化设计、抢占式内核、支持内核线程以及动态装载内核模块的能力。不只如此,Linux还避其微内核设计上性能损失的缺陷,让全部事情都运行在内核态,直接调用函数,无需消息传递。至今,Linux是模块化的、多线程的以及内核自己可调度的操做系统。实用主义再次占了上风。
当Linus和其余内核开发者设计Linux内核时,他们并无彻底完全地与Unix诀别。他们充分地认识到,不能忽视Unix的底蕴(特别是Unix的API)。而因为Linux并无基于某种特定的Unix,Linus和他的伙伴们对每一个特定的问题均可以选择已知最理想的解决方案——在有些时候,固然也能够创造一些新的方案。如下是对Linux内核与Unix各类变体的内核特色所做的分析比较:
·Linux支持动态加载内核模块。尽管Linux内核也是单内核,但是容许在须要的时候动态地卸除和加载部份内核代码。
·Linux支持对称多处理(SMP)机制,尽管许多Unix的变体也支持SMP,但传统的Unix并不支持这种机制。
·Linux内核能够抢占(preemptive)。与传统的Unix不一样,Linux内核具备容许在内核运行的任务优先执行的能力。在其余各类Unix产品中,只有Solaris和IRIX支持抢占,可是大多数传统的Unix内核不支持抢占。
·Linux对线程支持的实现比较有意思:内核并不区分线程和其余的通常进程。对于内核来讲,全部的进程都同样—只不过其中的一些共享资源而已。
·Linux提供具备设备类的面向对象的设备模型、热插拔事件,以及用户空间的设备文件系统(sysfs)。
·Linux忽略了一些被认为是设计得很拙劣的Unix特性,像STREAMS,它还忽略了那些实际上已经根本不会使用的过期标准。
·Linux体现了自由这个词的精髓。函数
现有的Linux特性集就是Linux公开开发模型自由发展的结果。若是一个特性没有任何价值或者创意不好,没有任何人会被迫去实现它。相反的,在Linux的发展过程当中已经造成了一种值得称赞的务实态度:任何改变都要针对现实中确实存在的问题,通过完善的设计并有正确简洁的实现。因而,许多其余现代Unix系统包含的特性,如内核换页机制,都被绝不迟疑的引入进来。
无论Linux和Unix有多大的不一样,它身上都深深地打上了Unix烙印性能