[轉]有關微內核OS史上最透徹一篇（剪輯、排版）

本文由知名博主Dog250投稿Linux閱碼場原創發表。
《有關微內核OS史上最透徹一篇 - 寫於華爲鴻蒙發佈一週之際》
剪輯自騰訊雲

一、微內核與宏內核

情景分析。
我就以普通的讀取文件的read調用，以Minix爲例，展現一下其行爲：

這裏須要解釋的是，上述情景的每個步驟看樣子都在進行進程間通訊(IPC)。確實，這就是微內核的特點之所在。

爲了讓系統核心的服務進程好比FS，MM更好的對每個用戶進程服務，在這些進程內部，均保存着系統全部進程的當前與本服務進程相關信息的快照。

FS進程請求SYS進程將從磁盤讀取的內容複製到用戶進程P的緩衝區，這一步是沒有用戶進程參與的，因此FS進程至少要知道用戶進程P的內存信息元數據，這樣纔可讓內核態的SYS進程完成複製操做。
其實，能夠這樣理解，在微內核中，FS，MM這些服務進程的邏輯以及快照數據在宏內核中就是對應內核自己的，只不過它們的訪問方式不一樣：

• 宏內核經過函數調用訪問特定的邏輯和數據。
• 微內核經過IPC(進程間通訊)訪問特定的邏輯和數據。

做爲對比，咱們看一下宏內核Linux是如何完成與上面的情景IPC等價的操做步驟的：

看樣子一樣是read讀取文件，微內核只是把宏內核的縱向通訊換成了橫向通訊而已。然而這個一縱一橫的背後，卻隱藏着大不一樣。

• 縱向通訊是實際發生的服務調用，即物理通訊。
• 橫向通訊是對等層通訊，即邏輯通訊。【這也是影響性能的核心因素】採用橫向通訊方案，當然損害了性能，但獲得的更多。

對照OSI以及TCP/IP分層模型，以上的說辭便再熟悉不過了。

若是隻是爲介紹微內核的運行原理和流程，我想到這裏已經結束了，下面該能夠愉快地看代碼了。然而微內核在現實中並不是能夠和宏內核分庭抗禮，咱們不使用它，不接受它，除了商業和生態因素致使的先入爲主以外，還有一個更加劇要的因素，即 性能。

二、性能對照

微內核性能太差了！ 全部人都認爲微內核性能差是由於IPC開銷大，系統調用開銷大所致使。固然，我也是這麼認爲。可是這只是事情的一面，事情還有另外一面。

關於微內核的話題，無外乎就是：

• 內核精簡，僅保留最核心的，其它所有給用戶態。
• 模塊化，可插拔，易於擴展。
• 安全，相互隔離，互不影響，能夠採起不一樣的安全策略。
• 數學可證實。
• 性能...
• ...

好多話題網上一搜一籮筐，大多數都是形而上的套話，也不想在這裏再次複製粘貼。

接下來我僅僅針對 性能 方面來對微內核進行一個定性的評估。另外，我嘗試爲微內核的性能表現作一番洗白。

a.通訊模型

一說到對等層的邏輯通訊，最終仍是要落實到縱向的物理通訊來落地，仍然以我比較熟悉的網絡方面來類比。典型的TCP/IP的通訊模型以下：

對於Minix微內核的read場景，和TCP/IP的模型幾乎一致，在橫向對等IPC之下，真正落地的是縱向通訊。對應上述IPC橫向邏輯通訊過程的縱向實際流程以下圖所示：

只要稍微一看這個圖，第一個個感受就是 這太TM繁瑣了！ 宏內核一個系統調用的事，微內核的IPC居然要12個系統調用，並且僅僅是send/receive重複6對！如此設計性能顯然好不了，意義何在呢？這個後面會講。

對於微內核而言，只須要send，receive兩個系統調用就夠了，全部的系統功能均可以經過send/receive兩個系統調用封裝IPC消息來完成。
對應的，相似FS，MM這樣的服務進程，就像普通的Web服務器守護進程那樣，在一個大循環裏等待receive就行了。

極簡主義的典範，不是嗎？這讓咱們能夠聯想到RISC處理器，看它們的彙編指令時，訪存尋址只有load/store兩個指令，也是極簡主義的典範。

極簡歸極簡，可是請看看上面那繁瑣的流程，在宏內核中一個read系統調用的事，在Minix微內核中居然要整整12個系統調用才能完成。回到上面的話題， 性能何在？效率何在？意義何在？

這是微內核飽受詬病的核心。

確實，純傳統IPC的方案，如此多的系統調用，開銷是很是可觀的。然而，經過以太網的發展史，咱們或許能夠看到曙光。

b.共享總線與交換機模式

咱們看看早期的共享總線式以太網：

[注]工做方式：CSMA/CD（載波監聽多路訪問/衝突檢測）先聽後發，邊聽邊發，衝突中止，隨機延遲重發。

咱們對比一下宏內核：

也許是咱們對宏內核太熟悉了，咱們每天都在用Linux內核，不是嗎？這致使咱們可能看不到別的可能性，這個事實將咱們矇蔽在真相之下，使咱們看不到宏內核實際上是有很大問題的，好比多核的不可擴展性。【固然，Linux內核在多核擴展性方面一致在持續優化，這無可厚非，可是始終沒有一個讓人哇塞的方案...】

宏內核缺少訪問共享資源的有序仲裁機制，所以同步開銷會很是大，最直接的後果就是宏內核隨着處理器核心的增長而不可擴展。這個現狀和早期以太網是多麼類似， 「以太網隨着共享總線上接入的計算機數量的增長而性能陡降」。

全部使用內核服務的進程都在各自 隔離的上下文(現代操做系統之因此現代的緣由) 中訪問底層的共享資源，這是沒法仲裁的根源。

說回以太網，當事情發展到交換式以太網的時候，問題解決了，由於衝突域坍縮到了交換機的背板總線，做爲具有二層邏輯處理能力的交換機，它即可以進行必要的資源仲裁，好比排隊以及隊列的調度，實現數據包的存儲轉發：

數據包的有序排隊代替了對總線的無序爭搶，從而避免了衝突。

讓咱們看看微內核，與此是多麼類似：

咱們回看並思考一下以太網進化到交換式以太網時的情形。

面對交換式以太網，有人確定會質疑， 原來數據包能夠直接經過一根線飛到目的地，如今還要去交換機裏走一遭，還有經由交換機邏輯的處理，多了這麼多的步驟，如何能和曾經共享總線時一根線相比呢？

質疑者明顯是忽略了CSMA/CD的開銷。相比CSMA/CD的開銷，交換機的處理開銷與之作減法，最終化做了收益。【交換式以太網今後飛起，現在萬兆以太網都已是標配了】

類比以太網的發展歷史，若是咱們考慮多核處理器上宏內核的無序同步開銷，在微內核中加入帶有仲裁功能的服務進程後居然大大下降甚至消失了，是否是有一絲的欣慰呢？

有了交換機以後，人們忘記了CSMA/CD(雖然仍是要考試)，那麼若干年後，是否是也能忘掉spinlock【衝突原地等待】呢？

c.用戶態協議棧

其實，在咱們使用宏內核時也不是不明白專門進程處理專門事情的重要性，只是這種感受來得比較自發罷了，並無造成書面上的方法論。典型的例子就是最近幾年很是風靡的Linux用戶態協議棧。

爲何要構建用戶態協議棧【權限-內核資源空間-併發】，那明顯是由於內核協議棧性能低。用戶態協議棧能夠作到專核專用，進程上下文能夠徹底掌握數據包收包邏輯的全過程，更便於仲裁和協做。

若是用戶態協議棧抽象成一個服務，這是否是就和微內核思想一致呢？

此外，除了協議棧，不少別的邏輯也紛紛往用戶態搬遷，而且，在內核態自己，中斷也愈來愈線程化了，以便統一參與內核的調度。微內核的思想一直在背後起着做用。

三、發展趨勢

原本微內核的性能是軟肋，結果被我說的好像成了它的優點，有點不太雅。但其實，我表達的更多的是微內核表現出來的一種潛力。站在多核心可擴展性角度，多核平臺，無疑微內核的設計會更好，服務進程的仲裁可讓應用在多核平臺無鎖運行。

a.性能與擴展性爭論

不過不管如何，我認可性能確實是微內核的軟肋，特別是Minix的性能確實不咋地，但這也一樣意味着微內核能夠針對性能這個軟肋集中地進行優化。業界公認的性能比較好的微內核當屬QNX了，它被普遍部署在黑莓手機和汽車上，時間和存在能夠證實，它守住了它承諾的。

在UNIX歷史的長河中，一開始的系統就是奔着微內核的思想去的，好比最初的UNIX系統中會擁有一個專門負責調度和交換的swapper進程，直到如今，咱們依然能夠在UNIX/Linux中找到一個0號的swapper/idle進程，雖然它早就被淹沒在宏內核之中，不再行調度以及交換之事務了。

說到微內核的性能問題，我認爲在通過了30多年的發展後，微內核，宏內核之間的性能差距已經大大縮小了，這個關於兩種因爲設計理念的不一樣致使的性能差別話題在計算機的發展史上，歷來就沒有中止過：

• 微內核和宏內核。
• 跨平臺的Java語言和C語言。
• 跨平臺的語言Java和跨語言的平臺.NET。
• 解釋型腳本Python和C語言。
• CISC體系結構和RISC體系結構。
• ...

可是無一例外，最終誰也吊打不了誰，收益必有代價，大多數的紛爭最終走向了融合。

硬件技術的發展每每落後於軟件技術的發展，可是硬件技術倒是始終不斷髮展的，在此期間，軟件技術每每陷入了兩種理念的紛爭而稍有停滯，最終硬件技術跟上，彌補軟件性能的缺陷。甚至硬件能夠針對軟件的需求做出特殊的支持。

軟件提出需求，硬件實現。若是微內核在理論上證實確實好，僅僅IPC是個瓶頸的話，直接從硬件上着手優化，豈不是更好嗎？我想QNX，鴻蒙的設計應該也是這麼考慮的吧。

軟件硬件統一支持，我想微內核和宏內核之間最終也會是某種融合，我說的並不是Windows做爲混合內核的那種馬賽克式的融合，而是熔爐式的融合。

具體到微內核性能差的根因，咱們來聊一下IPC的優化。

b.IPC的優化

若是實現一個最基本最簡單的IPC，那麼內存拷貝就夠了。這通常是0.1到1.0的作法。先讓系統跑起來是最重要的， 完成比完美更重要 。【GNU Hurd內核的失敗就是由於斯托曼太過理想主義，追求完美...反例則是李納斯，追求完成。】

隨着硬件技術的發展，隨着系統對性能要求不斷提升，IPC必然要不斷優化，內存拷貝再也不適用，共享內存則更好，最終，可能直接使用硬件的某種機制，好比寄存器，DMA等機制來幫助實現IPC。若是有硬件機制直接提供IPC的支持，問題就解決了。

這個過程很是相似sendfile/splice系統調用的設計過程。

sendfile/splice的設計
____起初，Web服務器須要先將文件拷貝到Web服務器內部buffer，而後再將buffer拷貝到用戶的socket。這很相似傳統的IPC方案。
____然而隨着HTTP逐漸主宰互聯網，幾乎每個Linux服務器上均部署有Web服務器，誰還能忍受兩次拷貝的瓶頸，因而sendfile就呼之欲出了。sendfile僅僅提供一個外部把手，真正的數據並不須要拷貝到Web服務器的buffer，經過這個把手，數據能夠從文件直通到socket。
____用的人多了，需求在了，問題天然也就解決了，並且是從底層根本上解決。微內核的IPC也會是這樣的路子。

不過，目前尚未一個通用的使用在微內核上的IPC機制，相信QNX是有優化過的IPC的，可是不夠通用，而Android系統的Binder夠通用也還不錯，可是它並不針對微內核。卻是很是但願能看看鴻蒙是怎麼去優化的。

最後，我想說點兒有意思可是你們不怎麼關注的東西。

• 內核態訪問到空指針，系統就必定會崩潰panic嗎？ 並非！只要內核不想panic就不會panic崩潰。只要錯誤不足以影響硬件狀態，系統就不會無條件崩潰。內核之因此panic(或者藍屏)是由於它認爲這樣最安全。就像用戶態能夠捕獲SEGV信號同樣，內核照樣也能捕獲空指針訪問。而後恢復。前提是，你要確保即便發生了空指針錯誤，系統也是穩定的，即沒有數據結構被破壞。而這個在宏內核裏很難保證，由於全部東西都在一塊兒。在微內核中，事情反而更簡單些。首先，內核很小，出現問題的機率天然小，即使出現問題，也很容易知道如何去恢復而不會對其它結構形成損害；其次，不少重要的數據結構以及邏輯都在用戶態的服務進程中，好比文件系統，網絡協議棧，甚至驅動，這種服務進程擁有本身隔離的地址空間，即使是出現再嚴重的問題，也不會污染到操做系統其它的部分。
• 將Linux改爲微內核有多難？ 很難，但也不是不可能。首先，須要改變Linux特定代碼和數據的地址空間結構，說到底就是將它們映射在用戶態的空間而且給它們一套獨立的頁表。其次，爲它們分配好task_t並處理好調度。最終，最難的是調用方式，這意味着你須要徒手將函數調用改爲IPC，這讓人以爲還不如基於Minix改呢。把Linux的好的代碼移植進Linux？？
• 微內核不被人知真的是由於它的性能差嗎？ 我卻是以爲這個跟Linux內核關係很大。Linux內核太出名了，以致於幾乎全部人都認爲做爲一個操做系統內核就應該長得和Linux內核那樣。這個和Linux內核開源是分不開的。除了Linux內核，很難再看到其它的流行內核是開源的。遵循POSIX的QNX做爲一個類UNIX系統，它自己就是微內核的，若是QNX在1990i 年出現而且開源，可能你們眼裏的操做系統內核就應該是微內核了。什麼事情，只要說多了，那即是對的了。

總結

文章終於寫完了, 原本想就此結束的，但仍是想說點內心話。

最開頭說了，但願能經過本文裏的東西給你們帶來點 技術 ，也確實，我專門爲此在文中加入了源碼分析。但願真的是把技術講明白了，但畢竟這僅僅只是一篇文章，因此也就不能面面俱到，但即使是如此，我也但願本文至少能夠做爲關於微內核的科普，也就倍感欣慰了。

本文以鴻蒙操做系統做爲引子，但也只是引子，我沒見過鴻蒙系統真正的樣子，因此我也不去過多猜想，沒見過的東西，也沒參與，過後去指點江山，總以爲缺了點什麼。鴻蒙一出，發現網上瞬間出現這麼多精通操做系統設計和開發的專家，原來你們之前真的都是潛龍勿用啊，現在變身，飛龍在天了。

也真是替華爲感到遺憾，當年招聘的時候，有這麼多專家都化名爲鯤，潛在北冥不該召，現在一張PPT就讓他們集體化而爲鳥，怒而飛，更名爲鵬了...

操做系統這門學科在即便計算機專業內部也並不算大衆，由於它太底層，而且太複雜太無趣了，偏學術，讓人以爲老套。沒有漂亮產品妹子蹦蹦噠噠過來跟你對需求，也沒什麼班可加，完過後你們一塊兒去啤酒擼串，更多的時候是你本身一我的大半夜在家裏debug或者思考。

很難出成績，這意味着加薪週期會比較長。

動輒以兩年爲單位的研發週期長，不符合BAT等大型互聯網公司一年兩次考覈的快速迭代小步快跑理念，這意味着你可能連本身的工做都保不住。

多年不變的夯實的架構讓操做系統領域顯然沒有更多新的東西可作，這就像TCP/IP協議棧同樣，千年不變的底層架構顯然讓你的職業生涯並無多少機會去擁抱變化，這顯然和互聯網理念是背道而馳的。

說白了，不少人對此並不感興趣。

鴻蒙發佈以後，忽然發現不少人都是操做系統專家了，我想這是在蹭華爲的熱度而不是鴻蒙操做系統自己吧，由於操做系統自Windows 95，Windows XP以後，歷來都沒有再熱過。不信你回家問問本身的家人，除了Windows 95/XP以外，還據說過哪一個劃時代的操做系統。

最後，想噴我站隊華爲的，先給在下演示一下如何在鴻蒙操做系統上寫hello world再說吧，反正我沒見過，等我看見了，若是它真的不如人所願，我和你一塊兒噴。打架不會，噴人仍是有一套的。