一直都在學習或分析與內核相關的東西，無論宏內核Linux或微內核，微內核的社羣(社區有點窄，羣體又不明確，社區羣體吧，就社羣了)，一直想要在性能上超越Linux。從第一次微內核失敗開始，每隔一段時間就會有微內核要媲美Linux的聲音出現：我們出了基於消息的IPC機制，顫抖吧Linux；我們出了基於capability的安全機制，顫抖吧Linux。而Linux很遺憾的沒有顫抖，相反Linus同志替Linux一遍又一遍的在語言和各種應用場合蹂躪微內核。
很遺憾的，我是站在微內核這邊的；並且我非常堅定的認爲微內核會取宏內核而代之，這可能是通過宏內核自行進行架構的更迭，也可能是某個設計完善的微內核取而代之。
我提一些點，關於當前微內核對Linux的優勢：
1.微內核更符合現代軟件工程思想。
現代軟件工程思想產生的益處都適用於微內核，可以更合理的設計，可以更容易理解，我說當前Linux內核的的複雜是非常嚴重且頭疼的事我想沒人反對，這似乎也是Linux內核BUG頻出的一個重要原因。
2.微內核更穩定
將驅動放到用戶態，將內核變爲一個機制性程序，微內核可以做到匪夷所思的小，如5000行。每一個驅動的崩潰都不會引起系統的整體崩潰，這是一個多麼誘人的特性，相比較Linux。。。
3.微內核伸縮性更強
Linux的伸縮性同樣很強，所以我也不能非常理直氣壯地強調這一優勢，但是我認爲這是需要提出的，畢竟微內核可以輕而易舉的在大量硬件平臺移植(當然，移植後也是沒有驅動的，不過大多都可以有個串口嘛)。
微內核的優勢的前兩條我認爲是非常重要的支柱性優勢，這是我堅挺微內核的原因。
於是爲什麼微內核從未在主流應用中有一片天地？
微內核大多用在一些嵌入式、或是TrustZone、hypervisor或其他我不知道的場合。沒有基於微內核的驅動、應用是微內核不能廣泛使用的原因嗎？我認爲這只是一言以蔽之的藉口而已。所謂沒有驅動，沒有應用，最重要的原因是因爲寫驅動、寫應用的人不看好它的未來；我認爲開發者都是聰明的，是最能評估這個平臺的生命力的。
我堅定地認爲微內核架構將會取代宏內核，所以我認真的分析了微內核爲什麼不能與宏內核媲美，我找到了3點，從內核技術的角度找到3點，我所謂從內核技術的角度指的是內核的效率。我看Linux的代碼，如果將Linux內核將內核與驅動割裂開來看，Linux真的很少，Linux內核本身活着的線程只有3個，Linux在執行initcall外設驅動相關的代碼之前，流程非常短暫。雖然Linux內核很龐大，但是Linux作爲一個內核，給計算機帶來的開銷真的是少的可憐。同時Linux又提供了極度高效率的系統調用、驅動模型，在Linux，一切一切都是爲了效率。
所以，我提出微內核對Linux的劣勢，只有一個：
1.效率。
有人可能覺着我要開始老調重彈，將幾百年前微內核基於IPC的失敗嘗試拿出來鞭撻一遍。
本文對幾百年前微內核的鞭撻截止到上一句。
微內核在很多年來有了非常優秀的進化，我認真的閱讀過seL4的白皮書，分析了它的各個系統調用。
也學習過Fiasco，也去看了幾遍zircon的系統調用、設計白皮書等等。當然，還是看的不夠多的，畢竟有些是閉源的。
這一系列的L4微內核或L4.1代微內核，從各個方面我都無法批評其設計的不合理之處，都是考慮的非常周到，對於安全、進程間通訊速度等微內核的劣勢有着非常完備的考慮，針鋒相對的解決了問題。
可惜，還是效率不足。
如何效率不足？如何就有效率？
所謂效率，並不是通過寄存器實現短消息就叫做效率，更不是什麼endpoint之流；當然，這都是極其優秀的設計。但是這並沒有得到最終的效率。所謂效率最直接的體現就是我打開一個文件可以飛快的打開，我打開很多文件，也能飛速的打開；我頻繁的來來回回讀寫文件，系統依舊反應流暢。對於一個內核，效率是用最小的開銷實現功能以承載更大的負載和用最快的響應速度實現操作。內核的設計面向進程，進程的業務、功能；能以更小的開銷承載更大更多的進程，能夠更快速的完成進程操作(包括處理進程所需的外部設備提供相關邏輯)。
當前的階段的微內核優秀嗎？
優秀，這一答案我是深以爲然的。
當前階段的微內核解決了效率問題嗎？
沒有。
