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

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

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

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

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

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

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

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

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

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