操作系统 - 操作系统结构

✅作者简介：人工智能专业本科在读，喜欢计算机与编程，写博客记录自己的学习历程。
个人主页：小嗷犬的个人主页
个人网站：小嗷犬的技术小站
个人信条：为天地立心，为生民立命，为往圣继绝学，为万世开太平。

---

---

操作系统的目标

• 用户目标：方便使用、容易学习、可靠、不易出错、高效等。
• 系统目标：易于实现与维护、灵活、可靠、不易出错、高效等。

复杂系统的构建必须考虑内部。

1. 不同目标之间往往存在冲突。
2. 不同需求之间需要进行权衡。
3. 在操作系统的发展历史中，曾多次出现因过于强调各种极致性能而导致设计结构不合理并最终失败的案例（Windows VISTA）。

---

操作系统的机制与策略

控制复杂度：机制与策略相分离

功能	机制	策略
登录	什么用户、以什么权限登录等	输入处理、策略文件管理、桌面启动加载等
调度	先到先服务、时间片轮转等	调度队列的设计、调度实体的表示、调度的中断处理等
···	···	···

优点：

1. 不同的策略适应不同的应用需求，而不需要重新实现对应的机制。
2. 通过持续优化具体的机制来不断完善一个策略的实现。

---

操作系统复杂度管理方法（M.A.L.H）

模块化（modularity）

1. 模块化通过"分而治之"原则，将一个复杂系统分解为一些列通过明确定义的接口进行交互的模块，并严格确保模块间的界限。
2. 模块划分要充分考虑高内聚和低耦合，使模块具有独立性。
3. 模块划分并不是越细越好，过多的模块会导致模块之间联系过多。

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

抽象（abstraction）

1. 抽象是在模块化的基础上，将接口与内部实现分离，从而使模块之间只需要通过抽象的接口进行相互调用，而无需关心各个模块的内部实现。
2. 一个好的抽象应该尽可能依从模块间的自然边界，并尽可能减少模块间的交互，从而减少错误在模块间的传递。

• 抽象实例
  • 虚拟内存抽象：应用无需关心物理地址，针对连续的虚拟地址空间设计即可。
  • 文件系统抽象：应用无需关心数据在存储介质上的位置，只需要通过定义好的文件系统接口（open / read / write）操作文件对应的数据。
• 宽进严出规则
  • 宽进：可以容忍各种可能的输入，抑制错误输入与恶意输入，避免错误进入模块内部。
  • 严出：严格控制模块对外的输出，从而减少错误在模块间的传播。

分层（layering）

1. 分层是通过将模块按照一定的原则进行层次的划分，约束每层内部模块间的交互方式与跨层次模块间的交互方式，从而有效减少模块之间的交互。
2. 一个模块只能和同层模块以及相邻的上层或下层模块进行交互。
3. 在确定层级后，可以先构建底层的模块，然后利用里层模块提供的功能与服务构建上层模块。

层级（hierarchy）

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

分层和层级的对比

• 相同点：都是为了减少模块间的交互，进一步控制系统复杂度。
• 不同点：分层是指不同类模块之间的层级，层级是指同类模块之间的分层。

---

操作系统内核架构

常见的操作系统内核架构有：

• 简要结构
• 宏内核
• 微内核
• 外核
• 多内核

• 用户态：运行在非特权级，受内核管理，使用内核服务。
• 内核态：运行在特权级，集中控制所有计算资源。

简要结构

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

• 优点：应用程序对操作系统服务的调用都是通过函数调用实现，效率很高。
• 缺点：缺乏隔离能力（在设计时就没有隔离），任何一个应用程序或操作系统模块出现问题，均有可能导致整个系统崩溃，因此难以运行复杂的操作系统。

如 MS-DOS：

• MSDOS.Sys 模块通过命令行接口与用户交互，并负
  责与驱动设备交互以实现对硬件设备的管理。
• IO 子系统实现对硬件设备IO 访问的管理，并以 IO 请
  求作为抽象为 MSDOS.Sys 和设备驱动提供服务。

宏内核架构

又称单内核，内核的所有模块（进程调度、内存管理、文件系统、设备驱动等）均运行在内核态（特权级），具有直接操作硬件的能力。
应用程序均运行在用户态（非特权级），受到内核管理，并通过系统调用使用内核提供的服务。

• 优势：拥有巨大且统一的社区和生态。
• 劣势：通用带来的安全性、可靠性问题；系统庞大带来的创新问题。

宏内核复杂度管理

• 模块化：可加载内核模块（LKM）机制。
• 抽象：将数据、设备、内核对象等均抽象为文件，并为上层应用提供统一的接口。
• 分层：一开始就具备的性质（THE操作系统）。
• 层级：存在一定程度的分层结构（调度、控制、内存）。

宏内核难以满足的场景与诉求

• 弹性扩展能力：很难仅仅通过简单的裁剪和扩展，使一个宏内核系统支持从 KB 级别到 TB 级别的场景。
• 硬件异构性：异构硬件往往需要一些定制化的方式来解决特定问题，这种定制化对于宏内核来说很难得到长期的支持。
• 功能安全：由于宏内核在故障隔离和时延控制等方面的缺陷，截至目前还无法通过汽车安全完整性认证（ASIL-D）。
• 信息安全：单点错误会导致整个系统出错，而现在有数百个安全问题（CVE）。
• 确定性时延：Linux 花费 10+ 年合并实时补丁，目前时延抖动仍然较大。

微内核架构

• 设计背景：最小化内核功能。
• 实现：对宏内核解耦，将单个功能或模块（文件系统、设备驱动）从内核中拆分出来，作为一个独立的服务部署到独立的运行环境中（一般在用户态），内核仅保留极少的必备功能。
• 优点：服务与服务之间是完全隔离的，单个服务出现故障或受到安全攻击，不会导致整个操作系统崩溃或被攻击，从而提高了操作系统的可靠性与安全性。
• 特性：机制与策略的进一步分离，也可以更方便地为不同场景定制不同的服务，从而更好地适应不同的应用需求。

宏内核与微内核的对比

宏内核：

1. 缺乏弹性扩展能力
2. 硬件异构性支持差
3. 功能安全尚无法完全保证
4. 信息安全存在隐患
5. 时延抖动较大
6. 拥有巨大的生态

微内核：

1. 易于扩展：直接添加一个用户态进程即可为操作系统增加服务
2. 易于移植：大部分模块与底层硬件无关
3. 更加可靠：在内核模式运行的代码量大大减少
4. 更加安全：服务与服务之间也存在进程粒度的隔离
5. 更加健壮：单个模式出现问题不会影响到整个系统
6. 性能较差：内核模块交互从函数调用变成了进程间通信
7. 生态欠缺

外核架构

• 设计背景：解决操作系统内核在对资源抽象上存在问题
  1. 过度的硬件资源抽象带来较大的性能损失。
  2. 针对所有应用的通用抽象对于具体的应用可能不是最优选择。
• 设计原则：尽可能让应用控制对硬件资源的抽象
  1. 库操作系统（LibOS）。
  2. 操作系统只管理 LibOS。
• 优势
  1. 动态组装 LibOS，最小化代码增强性能。
  2. 保证多个应用之间的隔离，提升安全性和可靠性。
• 劣势
  1. 缺乏场景通用性，生态差。
  2. 一旦面向复杂生态优势就会退化。
  3. 不同的 LibOS 间容易代码冗余。

多内核架构

• 设计背景：硬件结构呈现出的特性
  1. 多核（8）以及众核（8+）架构的流行使得一个服务器中存在许多处理器核。
  2. 异构SoC上可能集成多种功能、性能甚至指令集结构各异的处理器核，操作系统内部维护共享状态越来越难导致可扩展性差，甚至造成核多性能反降得现象。
• 设计原则：基于多硬件及其异构特性
  1. 将一个众核系统看成一个由多个独立处理器核通过网络互联而成的分布式系统。
  2. 在每个CPU核上运行一个独立的操作系统节点，节点间的交互由操作系统节点之上的进程间通信完成。

操作系统架构组合及其演替

操作系统框架架构举例

Android 系统框架

• 实现 Linux 内核与 Android 系统框架的解耦封装
• 提供用户态驱动模型使设备厂商不需要开源驱动源码

服务化架构与 Binder IPC

应用类似微内核架构的思想，系统框架组件化与服务化。

ROS 系统框架

• 面向机器人硬件场景的系统框架
• 提供基于场景的系统级服务、提供交互IPC机制
• 采用计算图的形式来组织各种服务，服务构成节点
• 每个节点执行一个具体计算处理：感知、融合、规划、控制等
• 不同的节点可看作不同的应用：接收、发布等
• 组件的设计以服务为中心
• 话题
• 2.0 引入数据分发服务，支持实时性