操作系统结构

操作系统的结构也和操作系统历史类似，经历了好几个阶段。在操作系统刚刚出现时，人们还没有意识到操作系统的存在，也没有将那些库函数称为操作系统。那个时候，人们想到什么功能，就把那个功能加进来，并没有对所有的功能进行统筹兼顾的计划。自然，那个时候的操作系统就是杂乱的、无结构的。

而随着操作系统的演化，人们对操作系统的认识逐步加深，操作系统慢慢多了一些结构。各种功能归为不同的功能块，每个功能块相对独立，又经过固定的界面互相联系。任意一个功能块都可以调用另一个功能块的服务。整个操作系统本身是一个巨大的单一体（monolithical system），运行在内核态下，为用户提供服务，如图3-9所示。

后来人们发现单一体的操作系统结构有很多缺点：
功能块之间的关系复杂，修改任意功能块导致其他所有功能块都需要修改，从而导致操作系统设计开发困难；

这种没有层次关系的网状联系容易造成循环调用，形成死锁，从而导致操作系统可靠性降低。
这时候，人们想到了人类社会中的层次关系，何不将人类熟悉的层次关系搬到操作系统设计里，定义操作系统的层次关系呢？将操作系统的功能分成不同层次，低层次的功能为紧邻其上一个层次的功能提供服务，而高层次的功能又为更高一个层次的功能提供服务。就像人类团体中的结构：村长→镇长→县长→市长……如图3-10所示。

从图3-9和图3-10可以看出，操作系统的所有功能都在内核态下运行。而这带来了几个问题。首先，操作系统的所有服务都需要进入内核态才能使用，而从用户态转换为内核态是有时间成本的，这样就造成操作系统效率低下。在操作系统还比较简单时这个问题并不突出，但随着操作系统功能和复杂性的增加，这种问题就十分明显了。

其次，前面说过，在内核态运行的程序可以访问所有资源，因此其安全性和可靠性要求十分高。在操作系统规模很小时，将其设计得可靠和安全并不困难。而且，在操作系统历史的早期也没有那么多安全问题，自然安全上的考虑就不用太多。但随着操作系统越来越大，破坏者的水平越来越高，操作系统的可靠性和安全性就变得很难达到。只要想一想，1400行代码的操作系统和4000万行代码的操作系统有什么区别就知道了。

因此，人们又想出了一个办法，就是微内核结构，即只将操作系统核心中的核心放在内核态运行，其他功能都移到用户态运行。这样就同时提高了效率和安全性（见图3-11）。

各种操作系统结构各有优缺点，但当前的趋势是第三种模式，即微内核的操作系统结构。至于这个微内核到底有多“微小”，则是仁者见仁、智者见智。

例如，美国卡内基梅隆大学开发的MACH操作系统的内核非常小，而微软公司的Windows XP的内核就大多了。

标签：功能,层次,功能块,内核,结构,操作系统
来源： https://blog.csdn.net/u010711495/article/details/118875883