基本介紹
- 中文名：核心
- 外文名：kernel
- 類別：軟體
- 發源時間：1991年10月
- 種類：單核心，雙核心，微核心
基本簡介,歷史發展,核心分類,單核心,微核心,混合核心,外核心,單核心與微核心的比較,優點,抽象隱藏,原始碼管理,並行開發,代碼覆蓋分析,大量信息,測試,套用測試,回歸測試,可擴展測試,追蹤缺陷,
基本簡介
核心，是一個作業系統的核心。是基於硬體的第一層軟體擴充，提供作業系統的最基本的功能，是作業系統工作的基礎，它負責管理系統的進程、記憶體、設備驅動程式、檔案和網路系統，決定著系統的性能和穩定性。
核心體系結構
核心體系結構現代作業系統設計中，為減少系統本身的開銷，往往將一些與硬體緊密相關的（如中斷處理程式、設備驅動程式等）、基本的、公共的、運行頻率較高的模組（如時鐘管理、進程調度等）以及關鍵性數據結構獨立開來，使之常駐記憶體，並對他們進行保護。通常把這一部分稱之為作業系統的核心。
程式可以直接地被調入計算機中執行，這樣的設計說明了設計者不希望提供任何硬體抽象和作業系統的支持，它常見於早期計算機系統的設計中。最終，一些輔助性程式，例如程式載入器和調試器，被設計到機器核心當中，或者固化在唯讀存儲器里。這些變化發生時，作業系統核心的概念就漸漸明晰起來了。
（概述圖片來源：）
歷史發展
大約從這時起開始使用兩“路”編號方法標註核心的開發，偶數號的核心（比如1.0、2.2、2.4、2.6）是穩定的，“產品”型號，同時，奇數號的核心版本（1.1、2.3）是前沿的或者“發展中的”核心。一個穩定的核心發布以後幾個月就開始新核心的開發工作。然而，2.5的開發工作是在2.4完成後幾十個月以後才開始的。
理解linux核心
理解linux核心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核心編程指南第3版單核心結構是非常有吸引力的一種設計，由於在同一個地址空間上實現所有低級操作的系統控制代碼的複雜性的效率會比在不同地址空間上實現更高些。 單核結構正趨向於容易被正確設計，所以它的發展會比微核心結構更迅速些。
單核心結構的例子：傳統的UNIX核心----例如伯克利大學發行的版本，Linux核心。
微核心
微核的目標是將系統服務的實現和系統的基本操作規則分離開來。例如，進程的輸入/輸出鎖定服務可以由運行在微核之外的一個服務組件來提供。這些非常模組化的用戶態伺服器用於完成作業系統中比較高級的操作，這樣的設計使核心中最核心的部分的設計更簡單。一個服務組件的失效並不會導致整個系統的崩潰，核心需要做的，僅僅是重新啟動這個組件，而不必影響其它的部分
混合核心
freebsd核心詳解混合核心實質上是微核心，只不過它讓一些微核結構運行在用戶空間的代碼運行在核心空間，這樣讓核心的運行效率更高些。這是一種妥協做法，設計者參考了微核心結構的系統運行速度不佳的理論。然而後來的實驗證明，純微核心的系統實際上也可以是高效率的。大多數現代作業系統遵循這種設計範疇，微軟公司開發的Windows作業系統就是一個很好的例子。另外還有XNU，運行在蘋果Mac OS X上的核心，也是一個混合核心。
混合核心的例子： BeOS 核心 ，DragonFly BSD，ReactOS 核心
外核心
外核心系統，也被稱為縱向結構作業系統，是一種比較極端的設計方法。
而外核的目標就是讓應用程式直接請求一塊特定的物理空間，一塊特定的磁碟塊等等。系統本身只保證被請求的資源當前是空閒的，應用程式就允許直接存取它。既然外核系統只提供了比較低級的硬體操作，而沒有像其他系統一樣提供高級的硬體抽象，那么就需要增加額外的運行庫支持。這些運行庫運行在外核之上，給用戶程式提供了完整的功能。
freebsd核心詳解
freebsd核心詳解理論上，這種設計可以讓各種作業系統運行在一個外核之上，如Windows和Unix。並且設計人員可以根據運行效率調整系統的各部分功能。
外核設計還停留在研究階段，沒有任何一個商業系統採用了這種設計。幾種概念上的作業系統正在被開發，如劍橋大學的Nemesis，格拉斯哥大學的Citrix系統和瑞士計算機科學院的一套系統。麻省理工學院也在進行著這類研究。
單核心與微核心的比較
單核心結構是非常有吸引力的一種設計，由於在同一個地址空間上實現所有複雜的低階作業系統控制代碼的效率會比在不同地址空間上實現更高些。
20世紀90年代初，單核心結構被認為是過時的。把Linux設計成為單核心結構而不是微核心，引起了無數的爭議。
單核結構正傾向於設計不容易出錯，所以它的發展會比微核心結構更迅速些。兩個陣營中都有成功的案例。
儘管Mach是眾所周知的多用途的微核心，人們還是開發了除此之外的幾個微核心。L3是一個演示性的核心，只是為了證明微核心設計並不總是低運行速度。它的後續版本L4，甚至可以將Linux核心作為它的一個進程，運行在單獨的地址空間。
QNX是一個從20世紀80年代，就開始設計的微核心系統。它比Mach更接近微核心的理念。它被用於一些特殊的領域；在這些情況下，由於軟體錯誤，導致系統失效是不允許的。例如太空梭上的機械手，還有研磨望遠鏡鏡片的機器，一點點失誤就會導致上千美元的損失。
很多人相信，由於Mach不能夠解決一些提出微核心理論時針對的問題，所以微核心技術毫無用處。Mach的愛好者表明這是非常狹隘的觀點，遺憾的是似乎所有人都開始接受這種觀點。
優點
抽象隱藏
原始碼管理
歷史上，從來沒有出現過用於Linux核心的正式的原始碼管理或修正控制系統。實際上，很多開發者實現了他們自己的修正控制器，但是並沒有官方的LinuxCVS檔案庫，讓LinusTorvalds檢查加入代碼，並讓其他人可以由此獲得代碼。修正控制器的缺乏，常常會使發行版本之間存在“代溝”，沒有人真正知道加入了哪些改變，這些改變是否能很好地融合，或者在即將發行的版本中哪些新內容是值得期待的。通常，如果更多的開發者可以像了解他們自己所做的改變一樣了解到那些變化，某些問題就可以得到避免。
非常有必要使用一個實時的、集中的檔案庫來保存對Linux核心的最新更新。每一個被核心接受的改變或者補丁都被作為一個改變集被追蹤。終端用戶和開發者可以保存他們自己的源檔案檔案庫，並根據需要可以通過一個簡單的命令用最新的改變集進行更新。對開發者來說，這意味著可以始終使用最新的代碼拷貝。測試人員可以使用這些邏輯的改變集合來確定哪些變化導致了問題的產生，縮短調試所需要的時間。甚至那些希望使用最新核心的用戶也可以直接利用實時的、集中的檔案庫，因為一旦他們所需要的部件或缺陷修復加入到核心中，他們就可以馬上進行更新。當代碼融合到核心時，任何用戶都可以提供關於這些代碼的即時反饋和缺陷報告。
並行開發
隨著Linux核心的成長，變得更加複雜，而且吸引更多開發者將注意力集中到核心的特定方面的專門開發上來，出現了另一個開發Linux方法的有趣改變。在2.3核心版本的開發期間，除了由LinusTorvalds發行的主要的一個核心樹之外，還有一些其他的核心樹。
在2.5的開發期間，核心樹出現了爆炸式的增長。由於使用原始碼管理工具可以保持開發的同步並行進行，這樣就可能實現開發的部分並行化。為了讓其他人在他們所做的改變被接受之前可以進行測試，有一些開發需要並行化。那些保持自己的樹的核心維護者致力於特定的組件和目標，比如記憶體管理、NUMA部件、改進擴展性和用於特定體系結構的代碼，還有一些樹收集並追蹤對許多小缺陷的糾正。
這種並行開發模型的優點是，它使得需要進行重大改變的開發者，或者針對一個特定的目標進行大量類似改變的那些開發者可以自由地在一個受控環境中開發，而並不影響其他人所用核心的穩定性。當開發者完成工作後，他們可以發布針對Linux核心當前版本的補丁，以實現到此為止他們所完成的改變。這樣，社區中的測試人員就可以方便地測試這些改變並提供反饋。當每一部分都被證明是穩定的之後，那些部分可以單獨地，或者甚至同時全部地，融合到主要Linux核心中。
（核心結構圖相冊部分圖片來源：）
代碼覆蓋分析
新工具為核心提供了代碼覆蓋分析的功能。覆蓋分析表明，在一個給定的測試運行時，核心中哪些行代碼被執行。更重要的是，覆蓋分析提示了核心的哪些部分還根本沒有被測試到。這個數據是重要的，因為它指出了需要再編寫哪些新測試來測試核心的那些部分，以使核心可以得到更完備的測試。
大量信息
在為將來的2.6Linux核心進行開的過程中，除了這些自動化的信息管理方法之外，開放原始碼社區的不同成員還收集和追蹤了數量驚人的信息。
例如，在KernelNewbies站點上創建了一個狀態列表，來保持對已經提出的核心新部件的追蹤。這個列表包含了以狀態排序的條目，如果它們已經完成了，則說明它們已經包含在哪個核心中，如果還沒有完成，則指出還需要多長時間。列表上很多條目的連結指向大型項目的Web站點，或者當條目較小時，連結指向一個解釋相應部件的電子郵件信息的拷貝。
測試
套用測試
測試背景
過去，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的人數的增加，這個系統的不足之處很快就暴露了出來。在以前，除非人們對缺陷的報告可以驚人地維持下去，缺陷經常被遺漏、遺忘或者忽略。
