现代操作系统原理与实践03：操作系统结构

目录

1 操作系统的目标

2 操作系统的机制与策略

3 操作系统复杂度管理方法

3.1 模块化（modularity）

3.2 抽象（abstraction）

3.3 分层（layering）

3.4 层级（hierarchy）

4 操作系统内核架构

4.1 简要结构

4.2 宏内核架构

4.2.1 宏内核特征

4.2.2 宏内核复杂度管理

4.2.3 宏内核优点

4.2.4 宏内核缺点

4.2.5 宏内核难以满足的场景

4.3 微内核架构

4.3.1 设计原则：最小化内核功能

4.3.2 微内核发展史

4.3.3 微内核优点

4.3.4 微内核缺点

4.4 混合内核架构

4.5 外核架构（Exokernel）

4.5.1 外核架构提出背景

4.5.2 外核架构特征

4.6 多内核架构（Multikernel）

5 操作系统框架结构

---

1 操作系统的目标

1. 用户目标：方便使用、容易学习、可靠、不易出错、高效等

2. 系统目标：易于实现与维护、灵活、可靠、不易出错、高效等

说明：复杂系统的构建必须考虑内部结构

① 不同目标之间往往存在冲突

② 不同需求之间需要进行权衡

③ 在操作系统的发展历史中，曾多次出现因过于强调各种极致性能而导致设计结构不合理并最终失败的案例（e.g. Windows VISTA）

2 操作系统的机制与策略

操作系统乃至计算机系统中控制复杂度的一个重要原则就是将机制与策略相分离

1. 策略（policy）：表示要"做什么"

2. 机制（mechanism）：表示"如何做"

说明1：机制与策略分离示例

以操作系统的调度系统为例，

① 策略包括先到先服务（First-Come-First-Serve，FCFS）、时间片轮转（Round Robin，RR）等

② 机制包括调度队列的设计、调度实体（如线程）的表示、调度的中断处理等

说明2：机制与策略分离的优点

① 操作系统可以通过多种不同的策略来适应不同的应用需求，而不需要重新实现对应的机制

② 通过优化具体的机制来不断完善一个策略的实现

3 操作系统复杂度管理方法

3.1 模块化（modularity）

1. 模块化通过"分而治之"原则，将一个复杂系统分解为一些列通过明确定义的接口进行交互的模块，并严格确保模块间的界限

2. 模块划分要充分考虑高内聚和低耦合，使模块具有独立性

3. 模块划分并不是越细越好，过多的模块会导致模块之间联系过多

说明：现代操作系统都存在一定程度的模块化结构，包括进程管理、内存管理、网络协议栈、设备驱动等

3.2 抽象（abstraction）

1. 抽象是在模块化的基础上，将接口与内部实现分离，从而使模块之间只需要通过抽象的接口进行相互调用，而无需关心各个模块的内部实现

2. 一个好的抽象应该尽可能依从模块间的自然边界，并尽可能减少模块间的交互，从而减少错误在模块间的传递

说明1：操作系统抽象示例

① 虚拟内存抽象

虚拟内存是物理内存的抽象，使得应用程序无需关心物理地址，只需要针对连续的虚拟地址空间进行设计

② 文件系统抽象

文件系统抽象使得应用程序无需关心数据在存储介质中的具体位置，只需要通过定义好的文件系统接口（e.g. open / read / write）操作文件对应的数据

说明2：一个模块的接口应该遵循"宽进严出"原则

① 宽进：可以容忍各种可能的输入，抑制错误输入与恶意输入，避免错误进入模块内部

② 严出：严格控制模块对外的输出，从而减少错误在模块间的传播

3.3 分层（layering）

1. 分层是通过将模块按照一定的原则进行层次的划分，约束每层内部模块间的交互方式与跨层次模块间的交互方式，从而有效减少模块之间的交互

2. 通常的原则是，一个模块只能和同层模块以及相邻的上层或下层模块进行交互

3. 在构建分层系统时，在确定层级后，可以先构建底层的模块，然后利用里层模块提供的功能与服务构建上层模块

3.4 层级（hierarchy）

层级是另一种模块的组织方式，他先将一些功能相近的模块组成一个具有清晰接口的自包含子系统，然后将这些子系统递归地组成一个具有清晰接口的更大的子系统

说明：层级与分层的关系

① 首先，层级和分层都是为了减少模块之间的交互，进一步控制系统复杂度

② 分层是指不同类模块之间的层级，而层级是指同类模块之间的分层

4 操作系统内核架构

4.1 简要结构

1. 简要结构操作系统将应用程序和操作系统放置在同一个地址空间（address space）中，无需底层硬件提供复杂的内存管理、特权级隔离功能

2. 简要结构的优点是应用程序对操作系统服务的调用都是通过函数调用实现，效率很高

3. 简要结构的缺点是缺乏隔离能力（在设计时就没有隔离），任何一个应用程序或操作系统模块出现问题，均有可能导致整个系统崩溃

说明1：简要结构操作系统示例

MS-DOS（Microsoft Disk Operation System）、FreeRTOS、uCos，这些操作系统一般主要运行在相对比较简单的硬件上。这些硬件通常没有现代意义上的内存管理单元MMU，隔离能力较弱或缺失，难以运行（往往也不需要运行）复杂的操作系统

说明2：MS-DOS作为一种简要结构操作系统，虽然缺乏隔离能力，但是依然采用了一定的模块化与层次结构降低复杂度

其中，

① MSDOS.Sys模块通过命令行接口与用户交互，并负责与驱动设备交互以实现对硬件设备的管理

② IO子系统实现对硬件设备IO访问的管理，并以IO请求作为抽象为MSDOS.Sys和设备驱动提供服务

4.2 宏内核架构

4.2.1 宏内核特征

1. 宏内核（Monolithic kernel）又称作单内核

2. 整个系统分为内核与应用两层，其中

① 操作系统内核的所有模块（e.g. 进程调度、内存管理、文件系统、设备驱动等）均运行在内核态（特权级），具有直接操作硬件的能力

② 应用程序均运行在用户态（非特权级），受到内核管理，并使用内核提供的服务（通过系统调用）

说明：典型的宏内核包括UNIX、Linux、FreeBSD等，典型宏内核架构如下图所示

4.2.2 宏内核复杂度管理

1. 模块化

① 现在操作系统内核均采用模块化策略来组织各个功能

② 为进一步提高功能的可扩展性，现代操作系统通常还提供可加载内核模块（Loadable Kernel Module，LKM）机制

2. 抽象

① 现代操作系统内核广泛采用抽象的方法来降低复杂度并提高可维护性

② 例如UNIX中将数据、设备、内核对象等均抽象为文件，并为上层应用提供统一的接口（一切皆文件）

3. 分层

① 宏内核架构的操作系统一开始就采用了分层的架构，如1968年提出的THE操作系统，第一次提出了操作系统的层次式结构设计方法

② 现代操作系统内核也均存在一定程度的分层结构，如Linux文件系统的分层结构

4. 层级

层级概念同样被广泛应用于内核的资源管理中，例如

①  调度子系统中对进程优先级的分类

② 控制组（cgroup）对进程层级的分类

③ 内存分配器对不同内存的分类

4.2.3 宏内核优点

1. 拥有巨大且统一的社区和生态

2. 针对不同场景优化了30年

4.2.4 宏内核缺点

1. 安全性与可靠性问题

模块之间没有很强的隔离机制

2. 实时性支持

系统太复杂导致无法做最坏情况时延分析

3. 系统过于庞大而阻碍了创新

Linux代码行数已经超过2千万，在这个庞大系统中进行创新变得越来越难。这使得一些较大的创新（如网络、文件系统、设备驱动等）开始往用户态迁移

4.2.5 宏内核难以满足的场景

1. 向上向下的扩展

很难仅仅通过简单的裁剪和扩展，使一个宏内核系统支持从KB级别到TB级别的场景

2. 硬件异构性

异构硬件往往需要一些定制化的方式来解决特定问题，这种定制化对于宏内核来说很难得到长期的支持

3. 功能安全

由于宏内核在故障隔离和时延控制等方面的缺陷，截至目前还无法通过汽车安全完整性认证（ASIL-D）

4. 信息安全

单点错误会导致整个系统出错，而现在有数百个安全问题（CVE）

5. 确定性时延

Linux花费10+年合并实时补丁，目前依然不确定是否能支持确定性时延

4.3 微内核架构

4.3.1 设计原则：最小化内核功能

1. 微内核的设计原则很多是针对宏内核存在的问题而提出的

2. 微内核在实现时，相当于对宏内核进行解耦，将单个功能或模块（e.g. 文件系统、设备驱动）从内核中拆分出来，作为一个独立的服务部署到独立的运行环境中（一般在用户态）

3. 内核仅保留极少的功能，为这些服务提供通信等基础能力，使他们能够相互协作，完成操作系统所必须的功能

4. 在微内核架构下，服务与服务之间是完全隔离的，单个服务出现故障或受到安全攻击，不会导致整个操作系统崩溃或被攻击，从而提高了操作系统的可靠性与安全性

5. 微内核架构带来了机制与策略的进一步分离，也可以更方便地为不同场景定制不同的服务，从而更好地适应不同的应用需求

说明1：微内核架构下文件创建示例

① 可见在微内核中，将File System和Disk Driver实现为2个和App地位一样的进程

② 在创建文件时，会有4次IPC的开销

说明2：微内核中的IPC都是跨进程的（因此也是跨地址空间的），所以IPC性能的高低很大程度上决定了微内核的性能

4.3.2 微内核发展史

4.3.2.1 Mach微内核

Mach是第一个真正意义上的微内核，实现了如下功能，

1. 任务和线程管理

① 任务是资源分配的基本单位

② 线程是执行的基本单位

2. 进程间通信（IPC）

通过端口（port）进行通信

3. 内存对象管理

即虚拟内存

4. 系统调用重定向

① 允许用户态处理系统调用

② 支持对系统调用的功能扩展，例如二进制翻译、跟踪、调试等

5. 设备支持

① 通过IPC实现（通过port来连接设备）

② 支持同步设备和异步设备

6. 用户态的多进程

① 类似用户态的线程库，支持wait / signal等原语

② 一个或多个用户态线程可映射到同一个内核线程

7. 分布式支持

可透明地将任务与资源映射到集群中的不同节点

说明：Mach的IPC性能较差

① Mach对IPC的设计过于通用

② 高性能IPC的设计与实现必然与体系结构相关，过度抽象将极大影响IPC的性能。而利用体系结构相关的状态进行优化，则可以将IPC性能提升到极致（L3/L4微内核设计者Jochen Liedtke）

4.3.2.2 L3/L4微内核

L4是第二代微内核的代表，此处着重说明如下2点，

1. 微内核最小化原则

一个操作系统内核的功能只有在将其放在内核态以外会影响整个系统的功能时，才能被防止在内核态

2. 高性能IPC（L4的IPC性能是比Mach快20倍）

① IPC仅传递信息

② 使用寄存器传参，限制消息长度

③ 内核去掉了IPC的权限检查等功能，交给用户态判断

说明：但是L4将系统服务的接口直接暴露给用户态，可能导致DoS攻击

4.3.2.3 seL4微内核

1. seL4在L4微内核的基础上引入capability机制增强微内核的安全性

2. capability机制允许更精确、更细粒度地给不同应用程序授予对内核对象的调用权

3. seL4是第一个完成形式化验证的内核，这些安全增强能力成为第三代微内核架构操作系统的重要特征

4.3.2.4 其他微内核

1. QNX Neutrino

① 使用Neutrino微内核

② 满足实时性要求，广泛用于交通、能源、医疗、航空航天领域

2. Google Fuchsia

① Google开发的全新OS，试图覆盖多个领域

② 使用Zircon微内核，该微内核仅提供IPC、进程管理、地址空间管理等功能

③ 基于capability机制实现访问控制

3. MNIX

① 教学使用的微内核

② 被用于Intel的ME模块

补充：Intel ME（Intel Management Engine），是一个嵌入式微控制器，他运行着一个轻量级微内核操作系统，为Intel的processor-based计算机系统提供各种功能和服务

4.3.3 微内核优点

1. 易于扩展

直接添加一个用户态进程即可为操作系统增加服务

2. 易于移植

大部分模块与底层硬件无关

3. 更加可靠

在内核模式运行的代码量大大减少

4. 更加安全

即使存在漏洞，服务与服务之间也存在进程粒度的隔离

5. 更加健壮

单个模式出现问题不会影响到整个系统

4.3.4 微内核缺点

1. 性能较差

主要是内核中模块的交互从函数调用变成了进程间通信

2. 生态欠缺

尚未形成像Linux一样具有广泛开发者的社区

4.4 混合内核架构

混合内核架构是宏内核与微内核的结合，将需要性能的模块重新置于内核态

1. MacOS / iOS = Mach微内核 + BSD + 系统框架

2. Windows NT = 微内核 + 内核态的系统服务 + 系统框架

说明：即使是Linux这种典型的宏内核架构，也开始融入微内核架构中的用户态驱动模块（e.g. UIO与VFIO）

4.5 外核架构（Exokernel）

4.5.1 外核架构提出背景

操作系统内核在硬件管理方面的主要功能是资源抽象与多路复用（multiplexing），其中对资源的抽象存在如下2个问题，

1. 过度的硬件资源抽象可能会带来较大的性能损失

2. 操作系统所提供的硬件资源抽象是针对所有应用的通用抽象，这些抽象对于具体的应用可能不是最优选择

因此，外核架构提出的背景就是在许多场景中，应用比操作系统更了解该如何去抽象和使用硬件资源，因此应该尽可能让应用控制对硬件资源的抽象

4.5.2 外核架构特征

1. 外核不提供硬件抽象

2. 外核不管理资源，只管理应用

① 负责将计算资源与应用绑定，以及资源的回收

② 保证多个应用之间的隔离

4.6 多内核架构（Multikernel）

1. 多内核架构提出的硬件背景

① 多核以及众核架构的流行使得一个服务器中通常存在成百上千个处理器核‘

② 异构SoC上可能集成多种功能、性能甚至指令集结构各异的处理器核

说明：多核带来的问题是OS内部维护共享状态越来越难（e.g. 维护cache一致性）；而且可扩展性非常差，核数增多，但性能不升反降

2. 多内核架构设计

① 将一个众核系统看成一个由多个独立处理器核通过网络互联而成的分布式系统

② 在每个CPU核上运行一个独立的操作系统节点，节点间的交互由操作系统节点之上的进程间通信完成

说明1：多内核的思路

① 默认的状态是划分而不是共享

② 维持多份状态的拷贝而不是共享一份状态

③ 显式的核间通信机制

说明2：操作系统的架构组合及其演进

5 操作系统框架结构

操作系统一般由操作系统内核和操作系统框架组成，下面以Android系统框架为例进行说明

1. 硬件抽象层（Hardware Abstraction Layer）

① 封装硬件实现细节，实现Linux内核与Android系统框架的解耦

② 通过提供用户态驱动模型，使得设备厂商不需要开源驱动源码（因为Android遵循Apache协议，而Linux内核遵循GPL协议）

2. Android库（Android library）

① 提供了一些方便Android应用开发的自定义库

② 重新实现了一些标准库（e.g. glibc），从而规避了LGPL协议

3. Android运行环境（Android RunTime，ART）

由于Android应用的主要开发语言是Java，因此需要一个运行时环境将应用从字节码转化为可执行代码

4. Android应用框架（Android application framework）

Android应用框架提供了应用运行所需的基本服务，包括服务管理（service manager）、活动管理（activity manager）等

说明：Android应用框架的服务化架构

Android系统框架的设计整体应用了类似微内核架构的思想，将系统框架组件化与服务化，各个组件依靠Binder IPC进行通信，从而将不同的服务进行解耦