微內核的結構

通用操作系統要滿足各種不同用戶的要求，因此對它在功能上的要求是“通用”，所以其功能是越多越好。而嵌入式操作系統就有所不同，因為嵌入式操作系統的用戶群以及對功能的要求有某種程度的“專用”性，所以在一個特定的應用中，嵌入式操作系統需要哪些功能、不需要哪些功能基本上是固定的。因此，這就給設計小內核創造了條件。

相對于通用計算機系統而言，內存在嵌人式系統中是更為稀缺珍貴的資源。因此，作為需要常駐內存的操作系統的內核，在滿足應用的前提下越小越好。

另外，為了滿足不同的應用需要，嵌人式實時操作系統作為嵌人式系統重要的軟件，應支持可裁剪性。換句話說，嵌人式實時操作系統的設計在結構上應高度模塊化，并要提供非常靈活的手段，讓系統開發者能根據實際需要進行選用。當然，也應允許用戶根據需要編寫自己的功能模塊，并可以很方便地集成到系統中。

目前，從操作系統現有的結構來看，對于嵌入式實時操作系統來說，使用微內核結構應該是一個較好的選擇。

在這里需要強調的是，微內核并不是通過減少內核的服務功能模塊而變小的，而是把內核中應提供的部分服務功能模塊移動到內核外來實現的。這一點看起來有些費解，其實也很簡單。還是拿到飯店吃飯為例，如果你按菜單點的某道菜肴，等了一會兒，你可能是吃到了這道菜，你作為一個顧客享受了這道菜肴，但是這道菜真的是這個飯店做的嗎?不一定，有可能就是其他飯店做的菜，只不過這個飯店在接收你的要求之后，它把消息發到另外一家飯店并讓他們把菜做出來，再拿到你的餐桌上罷了。如果一個飯店的大部分菜肴都可以這樣來提供，那么這個飯店所占用的土地面積一定會小得多。

其實，微內核的設計思想與上面所舉的例子一樣。如果把內核的某些服務模塊作為一個進程放在內核以外，那么當要求服務的進程有服務要求時，這個仍然是通過系統調用接口向內核提出服務申請，而系統調用接口接收到該申請后，則立即通過向內核外的服務進程發送一個消息來啟動這個服務進程，從而為要求服務的進程提供了相應的服務。顯然，這樣一來，就會使要求服務的進程和提供服務的進程都處在操作系統的用戶區而處在同一個層次上了，所以內核也就變小了。為了區別兩種不同的進程，把要求服務的進程叫做“客戶”，把提供服務的進程叫做“服務器”，這種微內核結構也叫做“客戶/服務器”結構。微內核的“客戶/服務器”結構示意圖如圖所示。

圖 微內核的客戶/服務器結構示意圖

在微內核中，由于客戶/服務器的這種結構使內核變得更便于維護，一旦某部分發生錯誤，不會影響其他部分的工作，并且很適合嵌人式系統可裁剪性的要求：如果系統不需要某種服務，則只要簡單地把相應的服務器刪掉即可。當然，系統設計人員也可根據實際需要對某一服務器進程進行修改，雨不會影響其他部分，再由于內核是通過消息與服務器聯系的，是動態鏈接的，因此在修改某個服務器進程后，只要對修改的服務器進行編譯即可，而沒有必要對整個操作系統進行編譯。

此外，這種結構也適用于分布式系統。當客戶需要遠程服務器服務時，只要在系統調用的庫函數中把客戶進程的請求裝配成數據包轉發給遠程的服務器，再接收遠程服務器所返回的結果，把結果再返回給客戶進程。對客戶進程來說，它像正常一樣使用系統調用，而不知道也沒有必要知道這個服務是來自本地還是來自遠程主機。

盡管可把原屬于內核的服務模塊移動到內核以外，但有幾項基本服務是沒有辦法這樣做的。例如，描述進程的進程控制塊一定應該是內核的內容，于是與進程控制塊相關的進程調度、進程創建、進程刪除等需要訪問進程控制塊的服務必須要保留在內核中;進程通信的管理當然也要保留在內核中;中斷的管理也要保留在內核中。總之，凡是需要使用處理器特權指令的功能模塊都要保留在內核中。