內核

內核，是一個操作系統的核心。是基於硬體的第一層軟體擴充，提供操作系統的最基本的功能，是操作系統工作的基礎，它負責管理系統的進程、內存、設備驅動程序、文件和網路系統，決定著系統的性能和穩定性。

現代操作系統設計中，為減少系統本身的開銷，往往將一些與硬體緊密相關的（如中斷處理程序、設備驅動程序等）、基本的、公共的、運行頻率較高的模塊（如時鐘管理、進程調度等）以及關鍵性數據結構獨立開來，使之常駐內存，並對他們進行保護。通常把這一部分稱之為操作系統的內核。

程序可以直接地被調入計算機中執行，這樣的設計說明了設計者不希望提供任何硬體抽象和操作系統的支持，它常見於早期計算機系統的設計中。最終，一些輔助性程序，例如程序載入器和調試器，被設計到機器核心當中，或者固化在只讀存儲器里。這些變化發生時，操作系統內核的概念就漸漸明晰起來了。

Linux的第一個公開版本是1991年10月的0.02版本，兩個月以後，在1991年12月，Linux發布了0.11版本，這是第一個可以不依賴於Minix就可以使用的獨立內核。

0.12版本發布一個月以後，在3月，版本號跳到了0.95，反映出系統正變得成熟，不僅如此，直到兩年後，也就是1994年3月，具有里程碑意義的1.0.0才完成。

大約從這時起開始使用兩“路”編號方法標註內核的開發，偶數號的內核（比如1.0、2.2、2.4、2.6）是穩定的，“產品”型號，同時，奇數號的內核版本（1.1、2.3）是前沿的或者“發展中的”內核。一個穩定的內核發布以後幾個月就開始新內核的開發工作。然而，2.5的開發工作是在2.4完成後幾十個月以後才開始的。

post-halloween文檔的大部分討論內容是用戶需要注意的主要改變，以及需要更新的系統工具（為了利用它們）。關心這一信息人的主要是那些期望提前了解2.6內核中有哪些內容的Linux發行商，還有終端用戶，這可以讓他們確定為了能利用新部件是否有需要升級的程序。

KernelJanitors項目保持了一個列表，內容是需要修復的較小缺陷和解決方法。這些缺陷解決方法中大部分是由於向內核打較大的補丁時需要改動很多部分代碼而導致的，比如有些地方會影響設備驅動程序。那些新近從事內核開發的人開始時的工作可以選擇列表中的條目，這樣讓他們可以通過小項目學習如何編寫內核代碼，同時有機會為社區做出貢獻。

還有，在另一個預發布的項目中，JohnCherry追蹤了在對每個已經發布的內核版本進行編譯時發現的錯誤和警告。這些編譯統計數字隨著時間的流逝一直持續下降，而且，以系統的形式來發布這些結果使得所取得的進展一目了然。在很多情況下，可以像使用KernelJanitors列表一樣來利用這些警告和錯誤消息中的一部分，因為編譯錯誤通常是由小的缺陷引起的，需要一些努力去修復。

最後，還有AndrewMorton的“must-fix”列表。由於他已經被選定為2.6內核發布后的維護者，他運用他的特權概括地列出了那些他認為在最終的2.6內核發布前最迫切需要解決方案的問題。must-fix列表中包含了內核Bugzilla系統中的缺陷，需要完成的部件，以及其他已知的問題，這些問題如不解決將阻礙2.6發布。這一信息可以幫助指明在新內核發布前還需要哪些步驟；對那些關心這一萬眾期待的2.6內核發布何時能完成的人來說，它還可以提供有價值的信息。

單內核（Monolithic kernel），是個很大的進程。它的內部又能夠被分為若干模塊（或是層次或其他）。但是在運行的時候，它是個單獨的二進位大映象。其模塊間的通訊是通過直接調用其他模塊中的函數實現的，而不是消息傳遞。

單內核結構在硬體之上定義了一個高階的抽象界面，應用一組原語(或者叫系統調用)來實現操作系統的功能，例如進程管理，文件系統，和存儲管理等等，這些功能由多個運行在核心態的模塊來完成。

儘管每一個模塊都是單獨地服務這些操作，內核代碼是高度集成的，而且難以編寫正確。因為所有的模塊都在同一個內核空間上運行，一個很小的bug都會使整個系統崩潰。然而，如果開發順利，單內核結構就可以從運行效率上得到好處。

很多現代的單內核結構內核，如Linux和FreeBSD內核，能夠在運行時將模塊調入執行，這就可以使擴充內核的功能變得更簡單，也可以使內核的核心部分變得更簡潔。

單內核結構是非常有吸引力的一種設計，由於在同一個地址空間上實現所有低級操作的系統控制代碼的複雜性的效率會比在不同地址空間上實現更高些。單核結構正趨向於容易被正確設計，所以它的發展會比微內核結構更迅速些。

單內核結構的例子：傳統的UNIX內核----例如伯克利大學發行的版本，Linux內核。

微內核（Microkernelkernel）結構由一個非常簡單的硬體抽象層和一組比較關鍵的原語或系統調用組成，這些原語僅僅包括了建立一個系統必需的幾個部分，如線程管理，地址空間和進程間通信等。

微核的目標是將系統服務的實現和系統的基本操作規則分離開來。例如，進程的輸入/輸出鎖定服務可以由運行在微核之外的一個服務組件來提供。這些非常模塊化的用戶態伺服器用於完成操作系統中比較高級的操作，這樣的設計使內核中最核心的部分的設計更簡單。一個服務組件的失效並不會導致整個系統的崩潰，內核需要做的，僅僅是重新啟動這個組件，而不必影響其它的部分

微內核將許多OS服務放入分離的進程，如文件系統,設備驅動程序,而進程通過消息傳遞調用OS服務。微內核結構必然是多線程的,第一代微內核,在核心提供了較多的服務,因此被稱為'胖微內核',它的典型代表是MACH。它既是GNU HURD也是APPLE SERVER OS的核心，可以說,蒸蒸日上.第二代為微內核只提供最基本的OS服務,典型的OS是QNX,QNX在理論界很有名,被認為是一種先進的OS。

微內核只提供了很小一部分的硬體抽象，大部分功能由一種特殊的用戶態程序：伺服器來完成。微核經常被用於機器人和醫療器械的嵌入式設計中，因為它的系統的關鍵部分都處在相互分開的，被保護的存儲空間中。這對於單核設計來說是不可能的，就算它採用了運行時載入模塊的方式。

微內核的例子：AIX，BeOS，L4微內核系列，.Mach中用於GNU Hurd和Mac OS X，Minix，MorphOS，QNX，RadiOS，VSTa。

混合內核它很像微內核結構，只不過它的的組件更多的在核心態中運行，以獲得更快的執行速度。

混合內核實質上是微內核，只不過它讓一些微核結構運行在用戶空間的代碼運行在內核空間，這樣讓內核的運行效率更高些。這是一種妥協做法，設計者參考了微內核結構的系統運行速度不佳的理論。然而後來的實驗證明，純微內核的系統實際上也可以是高效率的。大多數現代操作系統遵循這種設計範疇，微軟公司開發的Windows操作系統就是一個很好的例子。另外還有XNU，運行在蘋果Mac OS X上的內核，也是一個混合內核。

混合內核的例子： BeOS 內核，DragonFly BSD，ReactOS 內核

Windows NT、Windows 2000、Windows XP、Windows Server 2003以及Windows Vista等基於NT技術的操作系統。

外內核系統，也被稱為縱向結構操作系統，是一種比較極端的設計方法。

外內核這種內核不提供任何硬體抽象操作，但是允許為內核增加額外的運行庫，通過這些運行庫應用程序可以直接地或者接近直接地對硬體進行操作。

它的設計理念是讓用戶程序的設計者來決定硬體介面的設計。外內核本身非常的小，它通常只負責系統保護和系統資源復用相關的服務。

傳統的內核設計(包括單核和微核)都對硬體作了抽象，把硬體資源或設備驅動程序都隱藏在硬體抽象層下。比方說，在這些系統中，如果分配一段物理存儲，應用程序並不知道它的實際位置。

freebsd內核詳解

而外核的目標就是讓應用程序直接請求一塊特定的物理空間，一塊特定的磁碟塊等等。系統本身只保證被請求的資源當前是空閑的，應用程序就允許直接存取它。既然外核系統只提供了比較低級的硬體操作，而沒有像其他系統一樣提供高級的硬體抽象，那麼就需要增加額外的運行庫支持。這些運行庫運行在外核之上，給用戶程序提供了完整的功能。

理論上，這種設計可以讓各種操作系統運行在一個外核之上，如Windows和Unix。並且設計人員可以根據運行效率調整系統的各部分功能。

外核設計還停留在研究階段，沒有任何一個商業系統採用了這種設計。幾種概念上的操作系統正在被開發，如劍橋大學的Nemesis，格拉斯哥大學的Citrix系統和瑞士計算機科學院的一套系統。麻省理工學院也在進行著這類研究。

單內核結構是非常有吸引力的一種設計，由於在同一個地址空間上實現所有複雜的低階操作系統控制代碼的效率會比在不同地址空間上實現更高些。

20世紀90年代初，單內核結構被認為是過時的。把Linux設計成為單內核結構而不是微內核，引起了無數的爭議。

單核結構正傾向於設計不容易出錯，所以它的發展會比微內核結構更迅速些。兩個陣營中都有成功的案例。

儘管Mach是眾所周知的多用途的微內核，人們還是開發了除此之外的幾個微內核。L3是一個演示性的內核，只是為了證明微內核設計並不總是低運行速度。它的後續版本L4，甚至可以將Linux內核作為它的一個進程，運行在單獨的地址空間。

QNX是一個從20世紀80年代，就開始設計的微內核系統。它比Mach更接近微內核的理念。它被用於一些特殊的領域；在這些情況下，由於軟體錯誤，導致系統失效是不允許的。例如太空梭上的機械手，還有研磨望遠鏡鏡片的機器，一點點失誤就會導致上千美元的損失。

很多人相信，由於Mach不能夠解決一些提出微內核理論時針對的問題，所以微內核技術毫無用處。Mach的愛好者表明這是非常狹隘的觀點，遺憾的是似乎所有人都開始接受這種觀點。

排隊自旋鎖(FIFO Ticket spinlock)是 Linux 內核 2.6.25 版本中引入的一種新型自旋鎖，它解決了傳統自旋鎖由於無序競爭導致的“公平性”問題。本文詳細介紹了排隊自旋鎖的設計原理和具體實現，並與 Windows 操作系統採用的類似技術進行比較。

自旋鎖(Spinlock)是一種 Linux 內核中廣泛運用的底層同步機制。自旋鎖是一種工作於多處理器環境的特殊的鎖，在單處理環境中自旋鎖的操作被替換為空操作。當某個處理器上的內核執行線程申請自旋鎖時，如果鎖可用，則獲得鎖，然後執行臨界區操作，最後釋放鎖；如果鎖已被佔用，線程並不會轉入睡眠狀態，而是忙等待該鎖，一旦鎖被釋放，則第一個感知此信息的線程將獲得鎖。長期以來，人們總是關注於自旋鎖的安全和高效，而忽視了自旋鎖的“公平”性。傳統的自旋鎖本質上用一個整數來表示，值為1代表鎖未被佔用。這種無序競爭的本質特點導致執行線程無法保證何時能取到鎖，某些線程可能需要等待很長時間。隨著計算機處理器個數的不斷增長，這種“不公平”問題將會日益嚴重。排隊自旋鎖(FIFO Ticket Spinlock)是 Linux 內核 2.6.25 版本引入的一種新型自旋鎖，它通過保存執行線程申請鎖的順序信息解決了傳統自旋鎖的“不公平”問題。排隊自旋鎖的代碼由 Linux 內核開發者 Nick Piggin 實現，目前只針對x86 體系結構(包括 IA32 和 x86_64)，相信很快就會被移植到其它平台。

Linux 內核自旋鎖的底層數據結構 raw_spinlock_t 定義如下：

slock 雖然被定義為無符號整數，但是實際上被當作有符號整數使用。slock 值為 1 代表鎖未被佔用，值為 0 或負數代表鎖被佔用。初始化時 slock 被置為 1。線程通過宏 spin_lock 申請自旋鎖。如果不考慮內核搶佔，則 spin_lock 調用 __raw_spin_lock 函數，代碼如下所示：

清單 2. __raw_spin_lock 函數清單 3. LOCK_PREFIX宏在多處理器環境中 LOCK_PREFIX 實際被定義為“lock”前綴。

vmlinux編譯出來的最原始的內核文件，未壓縮。

zImage是vmlinux經過gzip壓縮后的文件。

bzImage bz表示“big zImage”，不是用bzip2壓縮的。兩者的不同之處在於，zImage解壓縮內核到低端內存(第一個640K)，bzImage解壓縮內核到高端內存(1M以上)。如果內核比較小，那麼採用zImage或bzImage都行，如果比較大應該用bzImage。

uImageU-boot專用的映像文件，它是在zImage之前加上一個長度為0x40的tag。

vmlinuz是bzImage/zImage文件的拷貝或指向bzImage/zImage的鏈接。

initrd是“initial ramdisk”的簡寫。一般被用來臨時的引導硬體到實際內核vmlinuz能夠接管並繼續引導的狀態。

測試背景

過去，Linux內核測試方法圍繞開放源代碼開發模型進行。由於代碼一經發布后就公開給其他開發者進行審查，因此從來沒有出現過一個與其他形式的軟體開發類似的正式的驗證周期。這種方法背後的理論依據是“TheCathedralandtheBazaar”中所謂的“Linus法則”（請查閱參考資料以獲得相關的參考），這一法則的內容為“眾人的眼光是雪亮的”。換句話說，高力度的審查可以找出大部分真正的大問題。

然而實際上，內核有很多複雜的相互聯繫。即使進行了足夠力度的審查，還是會漏過很多嚴重的缺陷。此外，最新的內核一經發布，終端用戶可以（也經常是）下載並使用。2.4.0發布時，社區中很多人都提議進行更有組織的測試，以保證特定測試和代碼審查的強度。有組織的測試包括運用測試計劃、測試過程中的可重複性等等。使用所有的三種方法比最初只使用兩種方法會帶來更高的代碼質量。

測試項目

最早對Linux開始進行有組織測試的貢獻者是Linux測試項目(LinuxTestProject，LTP)。這個項目的目的是通過更有組織的測試方法提高Linux的質量。這個測試項目的一部分是自動測試套件的開發。LTP開發的主要測試套件也叫做Linux測試項目。2.4.0內核發布時，LTP測試套件只有大約100個測試。隨著2.4和2.5版本Linux的發展與成熟，LTP測試套件也正在發展和成熟。當前，Linux測試項目包括超過2000個測試，而且這個數字還在增長。

在2.5的開發周期中，Linux測試項目所採用的另一個項目是，用LTP測試套件對Linux內核執行持續多日的回歸測試。人們用BitKeeper創建了一個實時的、集中的檔案庫，以隨時可以獲得Linux內核的快照。在沒有使用BitKeeper和快照時，測試人員不得不等到內核發布后才可以開始測試。內核只要發生了改變，測試人員就可以進行測試。

使用自動化工具來執行持續多日的回歸測試的另一個優點是，和上一次測試相比變化較小。如果發現了一個新的回歸缺陷，通常會容易地檢測出這個缺陷可能是哪個改變導致的。

同樣，由於是最新的改變，因此它在開發者的腦海中印象還比較深——希望這能讓他們更容易地記起並修訂相應的代碼。或許Linus法則應該有這樣一個結論，有一些缺陷比其他缺陷更容易被發現，因為那些正是持續多日的內核回歸測試所發現並處理的那些。在開發周期中和實際發布之前能夠每天進行這些測試，這就使那些只關注完整發行版本的測試者可以將精力集中於更嚴重和耗時的缺陷。

另外一個名為開放源代碼開發實驗室(OpenSourceDevelopmentLabs,OSDL)的團隊也為Linux測試做出了重要的貢獻。2.4內核發布后不久，OSDL創建了一個叫做可擴展測試平台(ScalableTestPlatform，STP)的系統。STP是一個自動化的測試平台，讓開發者和測試者可以運行OSDL硬體之上的系統所提供的測試。開發者甚至可以使用這個系統來測試他們自己的針對內核的補丁。可擴展測試平台簡化了測試的步驟，因為STP可以構建內核、設置測試、運行測試，並收集結果。然後得到結果以進行深入地比較。很多人無法接觸大型系統，比如具有8個處理器的SMP機器，而通過STP，任何人都可以在像這樣的大型系統上運行測試，這個系統(STP)的另一個好處就在於此。

自從2.4發布以來，對Linux內核的有組織測試最大的改進之一是缺陷追蹤。過去，在Linux內核中發現的缺陷會報告給Linux內核郵件列表，報告給特定組件或者特定體系的郵件列表，或者直接報告給維護髮現缺陷的那部分代碼的個人。隨著開發和測試Linux的人數的增加，這個系統的不足之處很快就暴露了出來。在以前，除非人們對缺陷的報告可以驚人地維持下去，缺陷經常被遺漏、遺忘或者忽略。

OSDL安裝了一個缺陷追蹤系統，來報告和追蹤Linux內核的缺陷。系統經過了配置，這樣當某個組件的缺陷被報告時，那個組件的維護者就會得到通知。維護者既可以接受並修復那個缺陷，或重新指定缺陷（如果最終確定實際上那是內核另外一部分的缺陷），也可以排除它（如果最終確定並不是真正的缺陷，比如錯誤配置的系統）。報告給郵件列表的缺陷還有丟失的危險，因為越來越多的電子郵件湧向那個列表。然而，在缺陷追蹤系統中，始終有對每一個缺陷及其當前狀態的記錄。

詞徠條圖冊