關於微核心的一點思考

        作業系統一般分為宏核心與微核心兩種。其中宏核心具有執行效率較高的特點，而微核心具有很好的可移植性。
        宏核心中對於系統調用由於是直接調用相應服務的函數，不存在處理序間通訊及進程切換的開銷，因此效率較高。但正由於各個模組之間的直接調用，導致模組之間出現了緊耦合，不利於模組之間的獨立。雖然Linux已經移植到了現今絕大多數的平台之上，但僅從系統結構的角度來說，微核心無疑更好一點。
        在微核心中，核心只需完成諸如系統啟動、系統硬體檢測、記憶體管理、進程管理、處理序間通訊的功能。其他的諸如滑鼠處理、鍵盤處理、檔案系統、GUI子系統則有不同的服務進程來實現。客戶進程採用處理序間通訊的方式來請求服務進程完成相應的功能。
        比如客戶進程要讀一個檔案，則通過系統調用的方式給檔案服務進程發送一個讀取檔案的請求訊息。此時，客戶進程則進入阻塞狀態，核心發生任務調度。當調度到檔案服務進程時，檔案服務進程獲得訊息，從訊息中取得適當的參數，完成實際的檔案讀取操作。然後，檔案服務進程也採用系統調用的方式給客戶進程發送一個訊息。在這個發送訊息的系統調用中，核心檢測客戶進程是否是因為等待當前訊息而阻塞的，如果是就把客戶進程喚醒。然後，核心即可返回服務進程或進行新的任務調度。
        從以上的說明來看，微核心除了完成必要的工作外，其實只是一個訊息的轉寄站，核心本身並不完成實際的工作，而是由相應的服務進程來完成的。因此移植的時候，只需要移植核心本身即可，而服務進程則不需要或只需進行很少的移植。這要看服務進程是否依賴於硬體而定。比如滑鼠服務進程，首先滑鼠中斷肯定是在核心中響應的，然後核心會通過一定的方式來找到具體的處理滑鼠中斷的服務進程並將發生中斷的訊息發送給該服務進程。在這裡就有兩種處理方式。一：核心中的中斷處理函數可以先從相應地連接埠讀取資料並更新相應的記錄滑鼠狀態的資料，然後直接附加在發送給服務進程的訊息中，或者由服務進程通過系統調用的方式從核心讀取。二：允許服務進程操縱連接埠，核心只發送發生中斷的訊息給服務進程即可。然後服務進程從相應的連接埠讀取資料。這兩種方式各有優劣，第一種把服務進程與具體的硬體分離，服務進程只依賴於核心，但增加了系統調用的開銷，而且核心需要對不同的中斷進行不同的處理，一來增加了核心的複雜度，二來也增加了核心與硬體的耦合度。而第二種方式則將服務進程與具體的硬體平台聯絡了起來，但這樣可以自由的處理訊息。核心只要通知服務進程發生了中斷即可，服務進程可以自由處理中斷而不必依賴於核心對特定訊息的參數及其順序的定義，也不必依賴於特定系統調用，而在系統調用及返回中肯定也伴隨著對特定資料的結構定義。
        宏核心與微核心各有優點，也各有缺點。但從系統結構及學習作業系統核心原理的角度來說，微核心無疑具有更大的優勢。而且隨著硬體的不斷髮展，微核心的效能問題必將退居次要的地位。而微核心的良好架構也特別適合模組化的開發，對於現今越來越複雜的軟體開發來說，無疑將提供巨大的好處。