操作系统-操作系统内核架构

本文转载自查看原文 2021-09-16 16:18 128 操作系统/ 操作系统概念

操作系统设计原则

操作系统的重要设计原则：策略与机制的分离

策略（Policy）：要做什么 —— 相对动态
机制（Mechanism）：怎么做 —— 相对静态

操作系统可仅通过调整策略来适应不同应用的需求

例子	策略	机制
登录	什么用户、以什么权限登录	输入处理、策略文件管理、桌面启动加载
调度	调度算法：Round-robin、 Earliest Deadline First ...	调度队列、调度实体（如线程）的表示、调度中断处理 ...

操作系统架构与演进

宏内核

定义

宏内核（Monolithic Kernel）：将管理进程的代码、管理内存的代码、管理各种 I/O 设备的代码、文件系统的代码、图形系统代码以及其它功能模块的代码，把这些所有的代码经过编译，最后链接在一起，形成一个大的可执行程序。这个大程序里有实现支持这些功能的所有代码，向用户应用软件提供一些接口，这些接口即系统 API 函数。

整个系统分为内核与应用两层

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

结构如下图所示。

以内存分配为例：

应用程序调用内存分配的 API（应用程序接口）函数。
处理器切换到特权模式，开始运行内核代码。
内核里的内存管理代码按照特定的算法，分配一块内存。
把分配的内存块的首地址，返回给内存分配的 API 函数。
内存分配的 API 函数返回，处理器开始运行用户模式下的应用程序，应用程序就得到了一块内存的首地址，并且可以使用这块内存了。

优缺点

优点：

宏内核拥有丰富的沉淀和积累
- 拥有巨大的统一的社区和生态
- 针对不同场景优化了30年

缺点：

宏内核的结构性缺陷
- 安全性与可靠性问题：模块之间没有很强的隔离机制
- 实时性支持：系统太复杂导致无法做最坏情况时延分析
- 系统庞大而阻碍了创新：Linux代码行数已经过2千万

宏内核难以满足的场景

向上向下的扩展
- 很难去剪裁/扩展一个宏内核系统支持从KB级别到TB级别的场景
硬件异构性
- 很难长期支持一些定制化的方式去解决一些特定问题
功能安全
- 一个广泛共识：Linux无法通过汽车安全完整性认证（ASIL-D）
信息安全
- 单点错误会导致整个系统出错，而现在有数百个安全问题（CVE）
确定性时延
- Linux花费10+年合并实时补丁，目前依然不确定是否能支持确定性时延

微内核

定义

微内核（MICRO-KERNEL）：与宏内核架构相反，它提倡内核功能尽可能少：仅仅只有进程调度、处理中断、内存空间映射、进程间通信等功能。

服务：开发者们把实际的进程管理、内存管理、设备管理、文件管理等服务功能，做成一个个服务进程。和用户应用进程一样，只是它们很特殊，宏内核提供的功能，在微内核架构里由这些服务进程专门负责完成。

消息：一种进程间通信的机制，应用程序要请求相关服务，就向微内核发送一条与此服务对应的消息，微内核再把这条消息转发给相关的服务进程，接着服务进程会完成相关的服务。服务进程的编程模型就是循环处理来自其它进程的消息，完成相关的服务功能。

下图中以文件系统为例，左边为宏内核架构，文件系统以API形式提供；右边为微内核架构，文件系统为一个服务，通过消息这种进程间通信方式请求服务。

微内核架构的设计原则：最小化内核功能

将操作系统功能移到用户态，称为"服务"（Server）
在用户模块之间，使用消息传递机制通信

以内存分配为例：

应用程序发送内存分配的消息，这个发送消息的函数是微内核提供的，相当于系统 API，微内核的 API（应用程序接口）相当少，极端情况下仅需要两个，一个接收消息的 API 和一个发送消息的 API。
处理器切换到特权模式，开始运行内核代码。
微内核代码让当前进程停止运行，并根据消息包中的数据，确定消息发送给谁，分配内存的消息当然是发送给内存管理服务进程。
内存管理服务进程收到消息，分配一块内存。
内存管理服务进程，也会通过消息的形式返回分配内存块的地址给内核，然后继续等待下一条消息。
微内核把包含内存块地址的消息返回给发送内存分配消息的应用程序。
处理器开始运行用户模式下的应用程序，应用程序就得到了一块内存的首地址，并且可以使用这块内存了。