操作系統和普通的大型應用程序項目類似，都涉及代碼組織方式的問題，但操作系統的獨特之處在于其核心部分必須運行在內核態，kernel model，所謂內核態嚴格講是指在該狀態下程序擁有對硬件(hardware)的所有控制權，運行在用戶態的程序做不到這一點。

有的同學可能會有疑問，操作系統(或者說內核)不都是核心部分嗎？嚴格來講像進程管理調度、內存管理等就是核心部分，但像驅動等就不是那么核心了，那么這一部分也需要放在內核態嗎？

圍繞這一劃分，出現了兩種操作系統的設計方式，關于這兩種設計方法的爭論就和復雜指令集(CISC)與精簡指令集(RISC)哪個更好一樣至今 沒有非常明確的定論 。

大一統，全部運行在內核態

最簡單的劃分就是沒有劃分 ，我們可以把所有內核代碼放在內核態，內核中的任何代碼都擁有控制硬件的全部特權，顯然這種設計方法非常簡單，因為操作系統設計者不用費心去想哪一部分該放在內核態。

由于全部內核程序都運行在內核態，編譯好的內核程序就是一個單獨的二進制可執行文件，這時的操作系統運行起來后就是一個大進程，所有內核代碼運行在一個單獨的地址空間中，這和我們實現的稍微復雜的單進程應用程序類似，這種大一統的設計就是所謂的宏內核，monolithic kernel，個人認為叫“一體化內核”更形象些。

這種組織方式和TCP/IP協議棧的分層實現有點類似。

現在內核代碼已經組織好了，畢竟內核是為上層應用提供服務的，那么上層應用該怎樣調用內核代碼呢？這就是系統調用的作用，system call。

上層應用程序通過系統調用與內核進行交互。

由于內核代碼唯一同一個地址空間中，因此內核中各部分的交互極為簡單，就是普通的函數調用，文件系統中的某塊cache可以非常容易的被虛擬內存系統共享使用。

但宏內核也是有缺點的，由于內核代碼位于同一個地址空間，代碼趨于復雜化，復雜就容易出錯，但內核和普通程序不同，一旦內核中某一模塊出現bug將導致整個內核崩潰，底層的內核崩潰后上層的應用程序就無法繼續正常推進。

當然也有人不在乎在這一點，Linus認為內核中有bug正常， 有bug就找到它、修復它而不是用某種機制試圖忽略它 ，沒錯，C++中的異常就是試圖忽略bug的機制，這就是為什么很多公司的規范中禁止使用異常的原因。

總之，內核崩潰后就必須重啟計算機。

保留核心，非必要不留在內核

為減少內核崩潰的風險，一個簡單的辦法就是讓內核盡量精簡，只保留核心部分運行在內核態，其它代碼以用戶態進程的形式運行，就像這樣：

運行在用戶態的操作系統程序被稱為server，像負責文件操作的File Server等，此時用戶進程想要使用操作系統提供的服務的話就必須借助進程間通信，inter-process communication，即IPC，借助內核，消息從一個進程發送到另一個進程然后等待返回。

這樣，內核只需要對上層應用提供一些簡單的接口即可，像創建進程、發送消息等，這種實現方式可以讓內核盡可能簡單，因為大部分內核程序都運行在用戶態，且運行在不同的地址空間中，此時設備驅動中的bug不會影響到內核，這種操作系統的實現方式就被稱為微內核， micro kernel。

就像宏內核那樣，微內核也有自己的缺點，那就是性能。由于宏內核的代碼都在同一個地址空間中，因此模塊間的交互可以非常簡單，簡單的函數調用即可，但模塊間交互對微內核來說則可能涉及進程間通信，看上圖，如果某個應用程序需要請求使用File Server，這條鏈路涉及到：

請求：應用程序 -> 內核 -> File server
返回：Filer server -> 內核 -> 應用程序

每一個"->"都涉及上下文切換，而這對宏內核來說則簡單很多。

現實中是什么樣子？

現實的操作系統中兩種實現方式都很常見，Linux以及許多Unix就是典型的宏內核，而Mac OS X 以及 Windows NT則一般認為是微內核，華為的鴻蒙Harmony OS則宣傳是微內核。

有趣的是，對Linus創建Linux影響極大的MINIX操作系統也是微內核，而Linux則是宏內核，難怪MINIX的作者——也是操作系統這門課的教授說過，如果Linus是他的學生的話那么操作系統系統這門課的期末考試Linus可能很難通過，哈哈，因為MINX的作者認為在Linux被創造出來的上世紀90年代竟然還有人以宏內核的方式來編寫操作系統，這簡直不可思議，而Linus則不以為意，并進行了火爆的回擊，關于這一段的八卦后續有機會和大家聊聊，非常有趣。

可以看到操作系統的設計方式就和CPU關于復雜指令集與精簡指令集的設計一樣分成了兩派， 關于宏內核與微內核孰優孰劣爭論至今依然沒有定論 。