Linux 操作系统架构简介
2013-03-07 22:03
211 查看
可以说,Linux 是21 世纪初最火的操作系统。注意,我只在这时说它是最“火”的,而不是最“好”
的。最好的定义对于每个人都不一样,为避免产生口水仗,我不在书中对Linux 进行评价。不过我得先
介绍一下Linux 的架构。
Linux 肯定是一款大内核操作系统,Linus Tovals 和Tanenbaum 的网上争论余音绕梁,相信知道此事
的读者一定还记得Linus 支持大内核的建议吧。虽然说Linux 是以大内核的方式运行,但编译方式已经吸
收了Windows 的动态加载模块的特点。也就是说,彼时(80‘s)的大内核和现在说的大内核不完全是一
个概念。那时候的大内核,不仅运行的时候所有驱动、文件系统、包括本书要讨论的协议栈要运行在内
核态,而且编译的时候,编译的文件必须同时被编译到一个大的二进制文件中。如今的内核,在编译的
时候,可以有选择的加入或减去某部分代码,使其编译出来的内核变“小”,而一些驱动程序和模块可以
在系统起来以后再加载。那么就单纯的那个内核镜像而言,真的还不算“大”,这个时候要说Linux 是大
还是小还真有点难。
操作系统内核可能是微内核,也可能是大内核(后者有时称之为宏内核Macrokernel)。按照类似封装
的形式,这些术语定义如下:
微内核(Microkernel kernel)――在微内核中,大部分内核都作为独立的进程在特权状态下运行,
它们通过消息传递进行通讯。在典型情况下,每个概念模块都有一个进程。因此,如果在设计中有一个
系统调用模块,那么就必然有一个相应的进程来接收系统调用,并和能够执行系统调用的其它进程(或
模块)通讯以完成所需任务。 在这些设计中,微内核部分经常只不过是一个消息转发站:当系统调用
模块要给文件系统模块发送消息时,消息直接通过内核转发。这种方式有助于实现模块间的隔离。(某
些时候,模块也可以直接给其它模块传递消息。)在一些微内核的设计中,更多的功能,如I/O 等,也
都被封装在内核中了。但是最根本的思想还是要保持微内核尽量小,这样只需要把微内核本身进行移植
就可以完成将整个内核移植到新的平台上。其它模块都只依赖于微内核或其它模块,并不直接直接依赖
硬件。 微内核设计的一个优点是在不影响系统其它部分的情况下,用更高效的实现代替现有文件系统
模块的工作将会更加容易。我们甚至可以在系统运行时将开发出的新系统模块或者需要替换现有模块的
模块直接而且迅速的加入系统。另外一个优点是不需要的模块将不会被加载到内存中,因此微内核就可
以更有效的利用内存。
大内核(Monolithic kernel)――单内核是一个很大的进程。它的内部又可以被分为若干模块(或
者是层次或其它)。但是在运行的时候,它是一个独立的二进制大映象。其模块间的通讯是通过直接调
用其它模块中的函数实现的,而不是消息传递。
单内核的支持者声称微内核的消息传递开销引起了效率的损失。微内核的支持者则认为因此而增加
的内核设计的灵活性和可维护性可以弥补任何损失。就像Linux 内核是微内核和单一内核的混合产物一
样。Linux 内核基本上是单一的,但是它并不是一个纯粹的集成内核。为什么Linux 必然是单内核的呢?
一个方面是历史的原因:在Linus 的观点看来,通过把内核以单一的方式进行组织并在最初始的空间中运
行是相当容易的事情。这种决策避免了有关消息传递体系结构,计算模块装载方式等方面的相关工作。
(内核模块系统在随后的几年中又进行了不断地改进。)
如果Linux 是纯微内核设计,那么向其它体系结构上的移植将会比较容易。实际的情况是,Linux 内
核的移植虽然不是很简单,但也绝不是不可能的。虽然这比微内核的移植需要更多的代码,但是Linux
的支持者将会提出,这样的Linux 内核移植版本比微内核更能够有效的利用底层硬件,因而移植过程中
的额外工作是能够从系统性能的提高上得到补偿的。核移植相对来说比较困难,但没有明显地阻碍程序员
团体的工作,他们已经热情高涨地把内核成功的移植到了现存的大部分实际系统中,更不用说类似掌上型
电脑的一些看起来很不实际的目标了。只要Linux的众多特点仍然值得移植,新的移植版本就会不断涌现。
这种特殊设计的权衡也不是很轻松就可以达到的,单内核的实现策略公然违背了传统的看法,后者
认为微内核是未来发展的趋势。但是由于单一模式(大部分情况下)在Linux 中运行状态良好,而且内
核移植相对来说比较困难,但没有明显地阻碍程序员团体的工作,他们已经热情高涨地把内核成功的移
植到了现存的大部分实际系统中,更不用说类似掌上型电脑的一些看起来很不实际的目标了。只要Linux
的众多特点仍然值得移植,新的移植版本就会不断涌现。
这不是自相矛盾吗?有的读者可能会疑惑了。其实,大和小内核之争已经过时了,连Windows 也号
称过微内核,那么有必要这么认真吗?其实只要记住,除了嵌入式,没有一款商用(包括开源)的操作
系统是以真正学术上的微内核方式存在。也就是说,所有的商用操作系统都是把驱动、文件系统、协议
栈等塞入内核之中,原因在于安全和效率。这就不必多说了。
的。最好的定义对于每个人都不一样,为避免产生口水仗,我不在书中对Linux 进行评价。不过我得先
介绍一下Linux 的架构。
Linux 肯定是一款大内核操作系统,Linus Tovals 和Tanenbaum 的网上争论余音绕梁,相信知道此事
的读者一定还记得Linus 支持大内核的建议吧。虽然说Linux 是以大内核的方式运行,但编译方式已经吸
收了Windows 的动态加载模块的特点。也就是说,彼时(80‘s)的大内核和现在说的大内核不完全是一
个概念。那时候的大内核,不仅运行的时候所有驱动、文件系统、包括本书要讨论的协议栈要运行在内
核态,而且编译的时候,编译的文件必须同时被编译到一个大的二进制文件中。如今的内核,在编译的
时候,可以有选择的加入或减去某部分代码,使其编译出来的内核变“小”,而一些驱动程序和模块可以
在系统起来以后再加载。那么就单纯的那个内核镜像而言,真的还不算“大”,这个时候要说Linux 是大
还是小还真有点难。
操作系统内核可能是微内核,也可能是大内核(后者有时称之为宏内核Macrokernel)。按照类似封装
的形式,这些术语定义如下:
微内核(Microkernel kernel)――在微内核中,大部分内核都作为独立的进程在特权状态下运行,
它们通过消息传递进行通讯。在典型情况下,每个概念模块都有一个进程。因此,如果在设计中有一个
系统调用模块,那么就必然有一个相应的进程来接收系统调用,并和能够执行系统调用的其它进程(或
模块)通讯以完成所需任务。 在这些设计中,微内核部分经常只不过是一个消息转发站:当系统调用
模块要给文件系统模块发送消息时,消息直接通过内核转发。这种方式有助于实现模块间的隔离。(某
些时候,模块也可以直接给其它模块传递消息。)在一些微内核的设计中,更多的功能,如I/O 等,也
都被封装在内核中了。但是最根本的思想还是要保持微内核尽量小,这样只需要把微内核本身进行移植
就可以完成将整个内核移植到新的平台上。其它模块都只依赖于微内核或其它模块,并不直接直接依赖
硬件。 微内核设计的一个优点是在不影响系统其它部分的情况下,用更高效的实现代替现有文件系统
模块的工作将会更加容易。我们甚至可以在系统运行时将开发出的新系统模块或者需要替换现有模块的
模块直接而且迅速的加入系统。另外一个优点是不需要的模块将不会被加载到内存中,因此微内核就可
以更有效的利用内存。
大内核(Monolithic kernel)――单内核是一个很大的进程。它的内部又可以被分为若干模块(或
者是层次或其它)。但是在运行的时候,它是一个独立的二进制大映象。其模块间的通讯是通过直接调
用其它模块中的函数实现的,而不是消息传递。
单内核的支持者声称微内核的消息传递开销引起了效率的损失。微内核的支持者则认为因此而增加
的内核设计的灵活性和可维护性可以弥补任何损失。就像Linux 内核是微内核和单一内核的混合产物一
样。Linux 内核基本上是单一的,但是它并不是一个纯粹的集成内核。为什么Linux 必然是单内核的呢?
一个方面是历史的原因:在Linus 的观点看来,通过把内核以单一的方式进行组织并在最初始的空间中运
行是相当容易的事情。这种决策避免了有关消息传递体系结构,计算模块装载方式等方面的相关工作。
(内核模块系统在随后的几年中又进行了不断地改进。)
如果Linux 是纯微内核设计,那么向其它体系结构上的移植将会比较容易。实际的情况是,Linux 内
核的移植虽然不是很简单,但也绝不是不可能的。虽然这比微内核的移植需要更多的代码,但是Linux
的支持者将会提出,这样的Linux 内核移植版本比微内核更能够有效的利用底层硬件,因而移植过程中
的额外工作是能够从系统性能的提高上得到补偿的。核移植相对来说比较困难,但没有明显地阻碍程序员
团体的工作,他们已经热情高涨地把内核成功的移植到了现存的大部分实际系统中,更不用说类似掌上型
电脑的一些看起来很不实际的目标了。只要Linux的众多特点仍然值得移植,新的移植版本就会不断涌现。
这种特殊设计的权衡也不是很轻松就可以达到的,单内核的实现策略公然违背了传统的看法,后者
认为微内核是未来发展的趋势。但是由于单一模式(大部分情况下)在Linux 中运行状态良好,而且内
核移植相对来说比较困难,但没有明显地阻碍程序员团体的工作,他们已经热情高涨地把内核成功的移
植到了现存的大部分实际系统中,更不用说类似掌上型电脑的一些看起来很不实际的目标了。只要Linux
的众多特点仍然值得移植,新的移植版本就会不断涌现。
这不是自相矛盾吗?有的读者可能会疑惑了。其实,大和小内核之争已经过时了,连Windows 也号
称过微内核,那么有必要这么认真吗?其实只要记住,除了嵌入式,没有一款商用(包括开源)的操作
系统是以真正学术上的微内核方式存在。也就是说,所有的商用操作系统都是把驱动、文件系统、协议
栈等塞入内核之中,原因在于安全和效率。这就不必多说了。
相关文章推荐
- Linux 操作系统架构简介
- Linux内核的整体架构简介
- linux操作系统基础(3)lamp架构的搭建和使用
- Linux ALSA声卡驱动之一:ALSA架构简介
- Linux的操作系统I2C驱动架构解说
- Linux的操作系统I2C驱动架构解说
- Linux 文件系统剖析: Linux SCSI 子系统剖析 分层 SCSI 架构简介
- Linux内核的整体架构简介
- linux操作系统架构
- Linux时钟简介 RedHat Linux操作系统修改时区的方法
- Linux操作系统的内存管理特性简介
- Linux ALSA声卡驱动之一:ALSA架构简介
- Linux内核的整体架构简介
- Linux ALSA声卡驱动之一:ALSA架构简介
- Linux的操作系统I2C驱动架构解说
- [操作系统]Linux 内核 3.1 将引入开源 CPU 架构
- linux 实时操作系统简介
- 实时 Linux 架构简介
- Linux内核的整体架构简介
- linux——lamp简介,架构搭建,Linux+Apache+Mysql/MariaDB+Php