第一章后面几节是纯概念类，以简单选择题为主，但不代表能轻松背得下来…

按照书上的顺序一个个介绍下去：

个人认为单纯说下总体的逻辑结构和大体上的考察方式，以此去做一个复习框架更好

书上写的虽然详细但总会觉得让人两眼一黑，有一个大体框架再说细节的补充吧

分层结构、模块化的两个结构特征以书上的为准，已经足够形象了，不必再多补充什么

关于优缺点的考察：

其实核心就是把握几个特性就行，清楚为什么有这个优点，为什么有这个缺点

但也没那么容易就能完全记住啊……

书上还有很多的进一步阐述，细节依旧还在书上

分层结构：

优点：

便于调试和验证可以采用书上的例子说明，这里不多说

易于扩充和维护、接口清晰固定，这句话稍微解释一下吧：

接口清晰固定是肯定的，因为一开始设计这一层的时候就会把这一批接口给设计好，不变

易于扩充、维护，想修改、替换一层的时候只需实现对上层的接口和下层接口的调用

只要对上层的接口依旧是实现的，不变的，那么你这一层怎么改都是不会有问题出现的

缺点：

仅可以调用相邻层，这个是特性决定的，上一层只能调用下一层相邻的，且是单向的

下一层是不能调用上面一层的接口的

效率低也是从这个特性理解，操作系统在高层调用一个程序，可能最终需要回到底层执行

即一条程序调用了每一层的接口，那么必然导致层与层之间产生大量的通信时间

模块化：

书上关于模块化的优点总结得稀碎，这里建议参考王道PPT来

优点：

模块划分是以功能划分的，所以逻辑自然清晰易于维护，哪边有问题去哪找

各个子模块之间也会有相应的暴露接口，但在开发的时候就可以明确接口的函数返回值等

也就是你这个模块即使没有完成，其他模块也可以按照设计开发时约定的接口来设计调用

所以说“同时并进”

相对应的，任何模块也可以直接调用其他模块，也是这样一个道理，直接通过接口就行

如果要增加拓展一项功能，支持新的功能、文件系统，只需要引入这个模块就行

只需要引入这个模块，这个驱动程序就可以完成新功能的拓展，所以说非常的方便

这里说的模块，其实就是图上面标的“进程管理”、“存储器管理”等类似的模块了

缺点：

接口的定义未必合理就是因为是事先安排好确定的一个接口约定

但谁都不知道开发过程中会不会说这个接口压根没法用或者会和别的接口冲突等

所以说定义未必合理

同时因为模块之间相互调用较多，所以到底是自身模块的问题，还是调用模块的问题

就很难区分，也就是说会有比较多的调用、调试难度

内核相关：

大内核，小内核：

其实区别就是在于拓展性的功能程序，一个放在了外部程序，一个集成在了内核程序之中

大内核：

优点肯定是性能较高，因为可以直接提供系统功能服务，而不需要去外部交互

缺点也是肯定的，因为代码量越多也就越难与维护，内部非常繁琐复杂

同时因为大量功能运行在内核态，所以一旦产生问题，就会直接导致系统整体性崩溃

书上对大内核的介绍也只是寥寥几句，所以重点要看的是微内核

微内核：

书上对其划分了最基本的功能，其实应该是有重复部分

第二十八页的最后一段和二十九页的第二整段几乎就是一个重复性的声明，只是详细化

对于基本功能就不再赘述，基本是涉及硬件底层最核心的一些功能

这边主要是对这里的东西、结合优缺点进行论述：

我想优点都是比较容易理解的，不多说了

性能低的源头基本就是其体系结构和特性决定的

因为这一批功能被移出内核，被作为单独的应用程序调用，所以当一个应用程序运行时

假如需要调用一堆非内核的外层服务器功能，那么就会导致核心态和用户态的反复切换

因为服务器在实现其功能的时候需要得到内核的支持，所以就需要先到核心态运行

然后完成以后就回到用户态，对于下一个功能模块的调用也是一样的

这样就会导致一个程序运行的时候假如涉及到多个功能模块，就会导致多次的状态切换

就会导致效率的大幅度降低

此外，各个应用程序之间的交互也是无法直接实现的，必须借助内核的通信实现

自然也就是更加费时间的事情了

外核，这个没什么可以说的，看书上就行了

注意下，即使是有外核的情况下，依旧是有操作系统内核的，不代表只有外核

以这个图来解释两种虚拟机管理程序

第一类的本质更类似于一个操作系统，直接对硬件资源进行管理

然后对CPU、硬盘、内存等进行虚拟化给不同的虚拟机，支持虚拟机上运行不同操作系统

第二类就更类似于一个应用程序

因为其是和宿主操作系统上的应用程序几乎是同等地位运行的

宿主操作系统上可以有自己运行的应用程序，也可以去运作这个虚拟机管理程序

在这个虚拟机管理程序上可以支持不同操作系统虚拟机的运行

对于上述任意一种虚拟机管理程序

当上层虚拟机在使用特权指令的时候，下层的管理系统会按情况进行响应

毕竟对于上层的虚拟机而言，它还以为自己运行在内核态，实际上运行在用户态

如果是操作系统发出的，那么就确切给一个内核执行的状态，即让真正硬件干

对于第一类就是由虚拟机管理程序去安排

第二类先由虚拟机管理程序截断这条指令，转为虚拟机管理程序向宿主操作系统系统调用

如果是用户的应用程序发出的，那么就“模拟”一个相应的处理过程，而不会实际调用

然后再来解释下这个图，物理资源的控制权我想是不用说的

第一类虚拟机管理系统约等于一个真正意义上的操作系统，第二类更像一个应用程序而已

资源分配方式上面

第一类因为其占据了资源分配主动权，分配的是物理资源，且可以如外核般分配资源

第二类其并没有对资源的主动权，只是被动由宿主操作系统给其分配虚拟化的资源

而其对这一些虚拟化的资源进行再度虚拟化划分

性能和可支持的虚拟化机器数量的多少的意思都是一样的

一个是底部就运行在硬件上，一个底部运行在操作系统之上

中间多了的一个操作系统就会导致一部分资源被操作系统给调用走

所以很自然第二类就不如第一类的性能好，可支持的数量多，因为其可拿到的资源更少

至于运行模式

这里就要稍微详细说下，第一类而言，只有这一个虚拟机管理程序是运行在内核态的

可以使用最高级别的特权指令，而对于上层的虚拟机，他们实际上运行在用户态

第二类而言，其部分模块是载入操作系统(参考操作系统的模块化)，部分运行于核心态

大部分还是运行在用户态的，当一个虚拟机需要执行特权指令的时候就会被截获

然后转向下一层真正操作系统的系统调用

注：操作系统引导这一块没看，有点太过于…

另外说下两类虚拟机管理系统的资源一些小问题：

首先是运行在虚拟机管理系统上的虚拟机，得到的肯定都是一些虚拟资源，这不用说

虚拟化技术又可以分为时分复用和空分复用技术，第四页，复习

而底层的就会因为是第一类还是第二类而会有一些不同之处

第一类能够直接调用硬件资源，而第二类实际上分配到的是宿主操作系统给他的虚拟资源

对模块结构的一些理解勘误：

首先调试验证困难实际上是指代开发过程中，一旦产生错误就很难精准定位去修复

主要指代的是开发过程、使用过程中出现错误后很难去找到修复的地方

而模块间逻辑清晰易于维护是指，当设计完了以后，要想去为其补充、修改很容易去定位

例如我想要修改、增加某个功能项，只需要去相应的模块里面改就行，和上面不一样

其实个人认为吧，对于整个408里面的概念问题，更多是要想这道题到底想要表达考什么

逆推这个题的答案，而不是说是文字游戏，更多可能是自身理解不够到位

对于分层结构的勘误、补充：

课后第一道选择题的思索，感觉还是理解不足

各层之间的定义不清晰，本质就是这样：

实际上的操作系统是各层之间可能需要相互调用的，这样一个死板的定义很难去完成

所以相应的一层层也很难去区分，这相当于一个抽象的逻辑模型

实际上想要以此去抽象这一整个操作系统会比较困难，所以就说每层难定义

课后习题说的结构，想要表达的大概率就是各层之间的接口实现以后，易于调用、维护