微核心和單核心
阿新 • • 發佈：2019-02-17
作業系統核心可能是微核心，也可能是單核心（後者有時稱之為巨集核心Macrokernel）。按照類似封裝的形式，這些術語定義如下：
微核心（Microkernelkernel）――在微核心中，大部分核心都作為單獨的程序在特權狀態下執行，他們通過訊息傳遞進行通訊。在典型情況下，每個概念模組都有一個程序。因此，假如在設計中有一個系統呼叫模組，那麼就必然有一個相應的程序來接收系統呼叫，並和能夠執行系統呼叫的其他程序（或模組）通訊以完成所需任務。
在這些設計中，微核心部分經常只但是是個訊息轉發站：當系統呼叫模組要給文件系統模組傳送訊息時，訊息直接通過核心轉發。這種方式有助於實現模組間的隔離。（某些時候，模組也能夠直接給其他模組傳遞訊息。）在一些微核心的設計中，更多的功能，如I/O等，也都被封裝在核心中了。但是最根本的思想還是要保持微核心儘量小，這樣只需要把微核心本身進行移植就能夠完成將整個核心移植到新的平臺上。其他模組都只依賴於微核心或其他模組，並不直接直接依賴硬體。
微核心設計的一個長處是在不影響系統其他部分的情況下，用更高效的實現代替現有文件系統模組的工作將會更加容易。我們甚至能夠在系統執行時將研發出的新系統模組或需要替換現有模組的模組直接而且迅速的加入系統。另外一個長處是無需的模組將不會被載入到記憶體中，因此微核心就能夠更有效的利用記憶體。
單核心（Monolithic kernel）――單核心是個很大的程序。他的內部又能夠被分為若干模組（或是層次或其他）。但是在執行的時候，他是個單獨的二進位制大映象。其模組間的通訊是通過直接呼叫其他模組中的函式實現的，而不是訊息傳遞。
單核心的支持者聲稱微核心的訊息傳遞開銷引起了效率的損失。微核心的支持者則認為因此而增加的核心設計的靈活性和可維護效能夠彌補任何損失。
我並不想討論這些問題，但必須說明很有趣的一點是，這種爭論經常會令人想到前幾年CPU領域中RISC和CISC的鬥爭。現代的成功CPU設計中包含了任何這兩種技術，就像Linux核心是微核心和單一核心的混合產物相同。Linux核心基本上是單一的，但是他並不是個純粹的整合核心。核心模組系統將微核心的許多長處引入到Linux的單核心設計中。（順便提一下，我考慮過一種有趣的情況，就是Linux的核心模組系統能夠將系統核心轉化成為簡單的不傳遞訊息的微核心設計。雖然我並不贊成，但是他仍然是個有趣的想法。）為什麼Linux必然是單核心的呢？一個方面是歷史的原因：在Linus的觀點看來，通過把核心以單一的方式進行組織並在最初始的空間中執行是相當容易的事情。這種決策避免了有關訊息傳遞體系結構，計算模組裝載方式等方面的相關工作。（核心模組系統在隨後的幾年中又進行了不斷地改進。）另外一個原因是充足的研發時間的結果。Linux既沒有研發時間的限制，也沒有深受市場壓力的發行進度。
任何的限制只有並但是分的對核心的修改和擴充。核心的單一設計在內部實現了充分的模組化，在這種條件下的修改或增加都並不怎麼困難。而且問題還在於沒有必要為了追求尚未證實的可維護性的微小增長而重寫Linux的核心。（Linus曾多次特別強調了如下的觀點：為了這點利益而損耗速度是不值得的。）
假如Linux是純微核心設計，那麼向其他體系結構上的移植將會比較容易。實際上，有一些微核心，如Mach微核心，就已成功的證實了這種可移植性的長處。實際的情況是，Linux核心的移植雖然不是很簡單，但也絕不是不可能的：大約的數字是，向一個全新的體系結構上的典型的移植工作需要30,000到60,000行程式碼，再加上不到20,000行的驅動程式程式碼。（並不是任何的移植都需要新的驅動程式程式碼。）粗略的計算一下，我估計一個典型的移植平均需要50,000行程式碼。這對於一個程式員或最多一個程式小組來說是力所能及的，能夠在一年之內完成。雖然這比微核心的移植需要更多的程式碼，但是Linux的支持者將會提出，這樣的Linux核心移植版本比微核心更能夠有效的利用底層硬體，因而移植過程中的額外工作是能夠從系統性能的提高上得到補償的。
這種特別設計的權衡也不是很輕鬆就能夠達到的，單核心的實現策略公然違背了傳統的看法，後者認為微核心是未來發展的趨勢。但是由於單一模式（大部分情況下）在Linux中執行狀態良好，而且核心移植相對來說比較困難，但沒有明顯地阻礙程式員團體的工作，他們已熱情高漲地把核心成功的移植到了現存的大部分實際系統中，更不用說類似掌上型電腦的一些看起來很不實際的目標了。只要Linux的眾多特點仍然值得移植，新的移植版本就會不斷湧現。
微核心（Microkernelkernel）――在微核心中，大部分核心都作為單獨的程序在特權狀態下執行，他們通過訊息傳遞進行通訊。在典型情況下，每個概念模組都有一個程序。因此，假如在設計中有一個系統呼叫模組，那麼就必然有一個相應的程序來接收系統呼叫，並和能夠執行系統呼叫的其他程序（或模組）通訊以完成所需任務。
在這些設計中，微核心部分經常只但是是個訊息轉發站：當系統呼叫模組要給文件系統模組傳送訊息時，訊息直接通過核心轉發。這種方式有助於實現模組間的隔離。（某些時候，模組也能夠直接給其他模組傳遞訊息。）在一些微核心的設計中，更多的功能，如I/O等，也都被封裝在核心中了。但是最根本的思想還是要保持微核心儘量小，這樣只需要把微核心本身進行移植就能夠完成將整個核心移植到新的平臺上。其他模組都只依賴於微核心或其他模組，並不直接直接依賴硬體。
微核心設計的一個長處是在不影響系統其他部分的情況下，用更高效的實現代替現有文件系統模組的工作將會更加容易。我們甚至能夠在系統執行時將研發出的新系統模組或需要替換現有模組的模組直接而且迅速的加入系統。另外一個長處是無需的模組將不會被載入到記憶體中，因此微核心就能夠更有效的利用記憶體。
單核心（Monolithic kernel）――單核心是個很大的程序。他的內部又能夠被分為若干模組（或是層次或其他）。但是在執行的時候，他是個單獨的二進位制大映象。其模組間的通訊是通過直接呼叫其他模組中的函式實現的，而不是訊息傳遞。
單核心的支持者聲稱微核心的訊息傳遞開銷引起了效率的損失。微核心的支持者則認為因此而增加的核心設計的靈活性和可維護效能夠彌補任何損失。
我並不想討論這些問題，但必須說明很有趣的一點是，這種爭論經常會令人想到前幾年CPU領域中RISC和CISC的鬥爭。現代的成功CPU設計中包含了任何這兩種技術，就像Linux核心是微核心和單一核心的混合產物相同。Linux核心基本上是單一的，但是他並不是個純粹的整合核心。核心模組系統將微核心的許多長處引入到Linux的單核心設計中。（順便提一下，我考慮過一種有趣的情況，就是Linux的核心模組系統能夠將系統核心轉化成為簡單的不傳遞訊息的微核心設計。雖然我並不贊成，但是他仍然是個有趣的想法。）為什麼Linux必然是單核心的呢？一個方面是歷史的原因：在Linus的觀點看來，通過把核心以單一的方式進行組織並在最初始的空間中執行是相當容易的事情。這種決策避免了有關訊息傳遞體系結構，計算模組裝載方式等方面的相關工作。（核心模組系統在隨後的幾年中又進行了不斷地改進。）另外一個原因是充足的研發時間的結果。Linux既沒有研發時間的限制，也沒有深受市場壓力的發行進度。
任何的限制只有並但是分的對核心的修改和擴充。核心的單一設計在內部實現了充分的模組化，在這種條件下的修改或增加都並不怎麼困難。而且問題還在於沒有必要為了追求尚未證實的可維護性的微小增長而重寫Linux的核心。（Linus曾多次特別強調了如下的觀點：為了這點利益而損耗速度是不值得的。）
假如Linux是純微核心設計，那麼向其他體系結構上的移植將會比較容易。實際上，有一些微核心，如Mach微核心，就已成功的證實了這種可移植性的長處。實際的情況是，Linux核心的移植雖然不是很簡單，但也絕不是不可能的：大約的數字是，向一個全新的體系結構上的典型的移植工作需要30,000到60,000行程式碼，再加上不到20,000行的驅動程式程式碼。（並不是任何的移植都需要新的驅動程式程式碼。）粗略的計算一下，我估計一個典型的移植平均需要50,000行程式碼。這對於一個程式員或最多一個程式小組來說是力所能及的，能夠在一年之內完成。雖然這比微核心的移植需要更多的程式碼，但是Linux的支持者將會提出，這樣的Linux核心移植版本比微核心更能夠有效的利用底層硬體，因而移植過程中的額外工作是能夠從系統性能的提高上得到補償的。
這種特別設計的權衡也不是很輕鬆就能夠達到的，單核心的實現策略公然違背了傳統的看法，後者認為微核心是未來發展的趨勢。但是由於單一模式（大部分情況下）在Linux中執行狀態良好，而且核心移植相對來說比較困難，但沒有明顯地阻礙程式員團體的工作，他們已熱情高漲地把核心成功的移植到了現存的大部分實際系統中，更不用說類似掌上型電腦的一些看起來很不實際的目標了。只要Linux的眾多特點仍然值得移植，新的移植版本就會不斷湧現。