操作系統-操作系統內核架構

本文轉載自查看原文 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。
處理器切換到特權模式，開始運行內核代碼。
微內核代碼讓當前進程停止運行，並根據消息包中的數據，確定消息發送給誰，分配內存的消息當然是發送給內存管理服務進程。
內存管理服務進程收到消息，分配一塊內存。
內存管理服務進程，也會通過消息的形式返回分配內存塊的地址給內核，然后繼續等待下一條消息。
微內核把包含內存塊地址的消息返回給發送內存分配消息的應用程序。
處理器開始運行用戶模式下的應用程序，應用程序就得到了一塊內存的首地址，並且可以使用這塊內存了。