|
物體中象核的部分 As part of the nuclear objects in the |
| 物體中象核的部分。藉指主要內容，實質。 艾思奇 《辯證唯物主義與歷史唯物主義》第三章：“ 馬剋思 恩格斯 在否定 黑格爾 的唯心主義哲學體係時，同時救出了它的辯證法中的合理內核。” 鄧友梅 《重放的鮮花·在懸崖上》：“對別人負責，對集體負責，互相都把對方的痛苦當作自己的痛苦，說穿了，共産主義精神不就是這麽個內核麽？” |
|
內核是操作係統最基本的部分。它是為衆多應用程序提供對計算機硬件的安全訪問的一部分軟件，這種訪問是有限的，並且內核决定一個程序在什麽時候對某部分硬件操作多長時間。直接對硬件操作是非常復雜的，所以內核通常提供一種硬件抽象的方法來完成這些操作。硬件抽象隱藏了復雜性，為應用軟件和硬件提供了一套簡潔，統一的接口，使程序設計更為簡單。
嚴格地說，內核並不是計算機係統中必要的組成部分。程序可以直接地被調入計算機中執行，這樣的設計說明了設計者不希望提供任何硬件抽象和操作係統的支持，它常見於早期計算機係統的設計中。最終，一些輔助性程序，例如程序加載器和調試器，被設計到機器核心當中，或者固化在衹讀存儲器裏。這些變化發生時，操作係統內核的概念就漸漸明晰起來了。 |
|
單內核 它為潛在的硬件提供了大量完善的硬件抽象操作。
微內核 衹提供了很小一部分的硬件抽象，大部分功能由一種特殊的用戶態程序：服務器來完成。
混合內核 它很像微內核結構，衹不過它的的組件更多的在核心態中運行，以獲得更快的執行速度。
外內核 這種內核不提供任何硬件抽象操作，但是允許為內核增加額外的運行庫，通過這些運行庫應用程序可以直接地或者接近直接地對硬件進行操作。
單內核
單內核結構在硬件之上定義了一個高階的抽象界面，應用一組原語(或者叫係統調用)來實現操作係統的功能，例如進程管理，文件係統，和存儲管理等等，這些功能由多個運行在核心態的模塊來完成。
儘管每一個模塊都是單獨地服務這些操作，內核代碼是高度集成的，而且難以編寫正確。因為所有的模塊都在同一個內核空間上運行，一個很小的bug都會使整個係統崩潰。然而，如果開發順利，單內核結構就可以從運行效率上得到好處。
很多現代的單內核結構內核，如linux和freebsd內核，能夠在運行時將模塊調入執行，這就可以使擴充內核的功能變得更簡單，也可以使內核的核心部分變得更簡潔。
單內核結構的例子：
1.傳統的unix內核，例如伯剋利大學發行的版本
2.linux內核
微內核
微內核結構由一個非常簡單的硬件抽象層和一組比較關鍵的原語或係統調用組成，這些原語僅僅包括了建立一個係統必需的幾個部分，如 綫程管理，地址空間和進程間通信等。
微核的目標是將係統服務的實現和係統的基本操作規則分離開來。例如，進程的輸入/輸出鎖定服務可以由運行在微核之外的一個服務組件來提供。這些非常模塊化的用戶態服務器用於完成操作係統中比較高級的操作，這樣的設計使內核中最核心的部分的設計更簡單。一個服務組件的失效並不會導致整個係統的崩潰，內核需要做的，僅僅是重新啓動這個組件，而不必影響其它的部分
微內核將許多os服務放入分離的進程,如文件係統,設備驅動程序,而進程通過消息傳遞調用os服務.微內核結構必然是多綫程的,第一代微內核,在核心提供了較多的服務,因此被稱為'胖微內核',它的典型代表是mach,它既是gnu hurd也是apple server os 的核心,可以說,蒸蒸日上.第二代為內核衹提供最基本的os服務,典型的os是qnx,qnx在理論界很有名,被認為是一種先進的os.
微內核的例子：
1.aix
2.beos
3.l4微內核係列
4.mach, 用於gnu hurd和mac os x
5.minix
6.morphos
7.qnx
8.radios
9.vsta
單內核與微內核的比較
單內核結構是非常有吸引力的一種設計，由於在同一個地址空間上實現所有低級操作的係統控製代碼的復雜性的效率會比在不同地址空間上實現更高些。
20世紀90年代初，單內核結構被認為是過時的。把linux設計成為單內核結構而不是微內核引起了無數的爭議。
現在，單核結構正趨嚮於容易被正確設計，所以它的發展會比微內核結構更迅速些。兩個陣營中都有成功的案例。微核經常被用於機器人和醫療器械的嵌入式設計中，因為它的係統的關鍵部分都處在相互分開的，被保護的存儲空間中。這對於單核設計來說是不可能的，就算它采用了運行時加載模塊的方式。
儘管mach是衆所周知的多用途的微內核，人們還是開發了除此之外的幾個微內核。l3是一個演示性的內核，衹是為了證明微內核設計並不總是低運行速度。它的後續版本l4甚至可以將linux內核在單獨的地址空間作為它的一個進程來運行。
qnx是一個從20世紀80年代就開始設計的微內核係統。它比mach更接近微內核的理念。它被用於一些特殊的領域，在這些情況下由於軟件錯誤導致係統失效是不允許的。例如航天飛機上的機械手，還有研磨望遠鏡鏡片的機器，一點點失誤就會導致上千美元的損失。
很多人相信，由於mach不能夠解决一些提出微內核理論時針對的問題，所以微內核技術毫無用處。mach的愛好者表明這是非常狹隘的觀點，遺憾的是似乎所有人都開始接受這種觀點。
混合內核
混合內核實質上是微內核，衹不過它讓一些微核結構運行在用戶空間的代碼運行在內核空間，這樣讓內核的運行效率更高些。這是一種妥協做法，設計者參考了微內核結構的係統運行速度不佳的理論。然而後來的實驗證明，純微內核的係統實際上也可以是高效率的。大多數現代操作係統遵循這種設計範疇，微軟視窗就是一個很好的例子。另外還有xnu，運行在蘋果mac os x上的內核，也是一個混合內核。
混合內核的例子：
beos 內核
dragonfly bsd
reactos 內核
windows nt、windows 2000、windows xp、windows server 2003以及windows vista等基於nt技術的操作係統
xnu
一些人認為可以在運行時加載模塊的單核係統和混合內核係統沒有區別。這是不正確的。混合意味着它從單核和微核係統中都吸取了一定的設計模式，例如一些非關鍵的代碼在用戶空間運行，另一些在內核空間運行，單純是為了效率的原因。
外內核
外內核係統，也被稱為縱嚮結構操作係統，使一種比較極端的設計方法。
它的設計理念是讓用戶程序的設計者來决定硬件接口的設計。外內核本身非常的小，它通常衹負責係統保護和係統資源復用相關的服務。
傳統的內核設計(包括單核和微核)都對硬件作了抽象，把硬件資源或設備驅動程序都隱藏在硬件抽象層下。比方說，在這些係統中，如果分配一段物理存儲，應用程序並不知道它的實際位置。
而外核的目標就是讓應用程序直接請求一塊特定的物理空間，一塊特定的磁盤塊等等。係統本身衹保證被請求的資源當前是空閑的，應用程序就允許直接存取它。既然外核係統衹提供了比較低級的硬件操作，而沒有像其他係統一樣提供高級的硬件抽象，那麽就需要增加額外的運行庫支持。這些運行庫運行在外核之上，給用戶程序提供了完整的功能。
理論上，這種設計可以讓各種操作係統運行在一個外核之上，如windows和unix。並且設計人員可以根據運行效率調整係統的各部分功能。
現在，外核設計還停留在研究階段，沒有任何一個商業係統采用了這種設計。幾種概念上的操作係統正在被開發，如劍橋大學的nemesis，格拉斯哥大學的citrix係統和瑞士計算機科學院的一套係統。麻省理工學院也在進行着這類研究。 |
|
| tunes project和unununiumos都進行無內核的嘗試. 無內核的係統is not limited to a single centralizing entry point. |
|
| 操作係統 |
|
紅旗5就是2.6內核了，期待中
轉：期待已久的2.6內核終於到來了。ibmlinuxtechnologycenter的paullarson暗中關註那些讓2.6成為有史以來最好內核的工具、測試和技術——從修正控製和回歸測試到缺陷追蹤和列表保持。
經過為期三年的積極開發，新2.6linux內核最近已經發佈了，在這期間，linux內核的開發和測試方法發生了一些有趣的變化。當前，開發內核的方法在很多方面與三年前沒什麽不同。不過，一些關鍵變化已經使整體的穩定性和質量得到了提高。
源代碼管理
歷史上，從來沒有出現過用於linux內核的正式的源代碼管理或修正控製係統。實際上，很多開發者實現了他們自己的修正控製器，但是並沒有官方的linuxcvs檔案庫，讓linustorvalds檢查加入代碼，並讓其他人可以由此獲得代碼。修正控製器的缺乏，常常會使發行版本之間存在“代溝”，沒有人真正知道加入了哪些改變，這些改變是否能很好地融合，或者在即將發行的版本中哪些新內容是值得期待的。通常，如果更多的開發者可以像瞭解他們自己所做的改變一樣瞭解到那些變化，某些問題就可以得到避免。
由於缺乏正式的修正控製器和源代碼管理工具，使得很多人提議使用一個名為bitkeeper的産品。bitkeeper是一個源代碼控製管理係統，很多內核開發者已經成功地將其應用於他們自己的內核開發工作中。最初的2.5內核發佈後不久，linustorvalds開始試用bitkeeper，以確定它是否能滿足他的需要。現在，主要的2.4和2.5內核的linux內核源代碼都是用bitkeeper來管理的。對大部分可能很少或者根本不關心內核開發的用戶來說，這一點看起來可能無關緊要。不過，在一些情況下，用戶可以受益於那些由於使用bitkeeper而帶來的開發linux內核的方法的改變。
使用bitkeeper的最大好處之一是補丁的融合。當多個補丁應用於同一基礎的代碼之上，並且其中一些補丁會對同一部分産生影響時，就可能會出現融合問題。一個好的源代碼管理係統可以自動地完成其中一些更為復雜的部分工作，這樣可以更快地融合補丁，並使更多的補丁加入到內核中。隨着linux內核開發者社區的擴大，非常需要修正控製器來幫助保持對所有改變的追蹤。由於每個人都可以將這些改變集成到主要的linux內核中，為保證補丁不會被遺忘並可以方便地融合和管理，bitkeeper等工具是必不可少的。
非常有必要使用一個實時的、集中的檔案庫來保存對linux內核的最新更新。每一個被內核接受的改變或者補丁都被作為一個改變集被追蹤。終端用戶和開發者可以保存他們自己的源文件檔案庫，並根據需要可以通過一個簡單的命令用最新的改變集進行更新。對開發者來說，這意味着可以始終使用最新的代碼拷貝。測試人員可以使用這些邏輯的改變集合來確定哪些變化導致了問題的産生，縮短調試所需要的時間。甚至那些希望使用最新內核的用戶也可以直接利用實時的、集中的檔案庫，因為現在一旦他們所需要的部件或缺陷修復加入到內核中，他們就可以馬上進行更新。當代碼融合到內核時，任何用戶都可以提供關於這些代碼的即時反饋和缺陷報告。
並行開發
隨着linux內核的成長，變得更加復雜，而且吸引更多開發者將註意力集中到內核的特定方面的專門開發上來，出現了另一個開發linux方法的有趣改變。在2.3內核版本的開發期間，除了由linustorvalds發行的主要的一個內核樹之外，還有一些其他的內核樹。
在2.5的開發期間，內核樹出現了爆炸式的增長。由於使用源代碼管理工具可以保持開發的同步並行進行，這樣就可能實現開發的部分並行化。為了讓其他人在他們所做的改變被接受之前可以進行測試，有一些開發需要並行化。那些保持自己的樹的內核維護者致力於特定的組件和目標，比如內存管理、numa部件、改進擴展性和用於特定體係結構的代碼，還有一些樹收集並追蹤對許多小缺陷的糾正。
圖1.linux2.5開發樹
這種並行開發模型的優點是，它使得需要進行重大改變的開發者，或者針對一個特定的目標進行大量類似改變的那些開發者可以自由地在一個受控環境中開發，而並不影響其他人所用內核的穩定性。當開發者完成工作後，他們可以發佈針對linux內核當前版本的補丁，以實現到此為止他們所完成的改變。這樣，社區中的測試人員就可以方便地測試這些改變並提供反饋。當每一部分都被證明是穩定的之後，那些部分可以單獨地，或者甚至同時全部地，融合到主要linux內核中。
在實際應用中測試
過去，linux內核測試方法圍繞開放源代碼開發模型進行。由於代碼一經發佈後就公開給其他開發者進行審查，因此從來沒有出現過一個與其他形式的軟件開發類似的正式的驗證周期。這種方法背後的理論依據是“thecathedralandthebazaar”中所謂的“linus法則”（請查閱參考資料以獲得相關的參考），這一法則的內容為“衆人的眼光是雪亮的”。換句話說，高力度的審查可以找出大部分真正的大問題。
然而實際上，內核有很多復雜的相互聯繫。即使進行了足夠力度的審查，還是會漏過很多嚴重的缺陷。此外，最新的內核一經發佈，終端用戶可以（也經常是）下載並使用。2.4.0發佈時，社區中很多人都提議進行更有組織的測試，以保證特定測試和代碼審查的強度。有組織的測試包括運用測試計劃、測試過程中的可重複性等等。使用所有的三種方法比最初衹使用兩種方法會帶來更高的代碼質量。
linux測試項目
最早對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內核的缺陷。係統經過了配置，這樣當某個組件的缺陷被報告時，那個組件的維護者就會得到通知。維護者既可以接受並修復那個缺陷，或重新指定缺陷（如果最終確定實際上那是內核另外一部分的缺陷），也可以排除它（如果最終確定並不是真正的缺陷，比如錯誤配置的係統）。報告給郵件列表的缺陷還有丟失的危險，因為越來越多的電子郵件涌嚮那個列表。然而，在缺陷追蹤係統中，始終有對每一個缺陷及其當前狀態的記錄。
大量信息
在為將來的2.6linux內核進行開的過程中，除了這些自動化的信息管理方法之外，開放源代碼社區的不同成員還收集和追蹤了數量驚人的信息。
例如，在kernelnewbies站點上創建了一個狀態列表，來保持對已經提出的內核新部件的追蹤。這個列表包含了以狀態排序的條目，如果它們已經完成了，則說明它們已經包含在哪個內核中，如果還沒有完成，則指出還需要多長時間。列表上很多條目的鏈接指嚮大型項目的web站點，或者當條目較小時，鏈接指嚮一個解釋相應部件的電子郵件信息的拷貝。
內核版本歷史
到現在我們很多人已經熟悉了linux內核的版本編號係統，不過andriesbrouwer提醒了我們實際上它是如何不規則的。
linux的第一個公開版本是1991年10月的0.02版本。兩個月以後，在1991年12月，linus發佈了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完成後幾ten個月以後纔開始的。
那麽我們什麽時候可以期待2.7呢？這不好說，不過在kerneltrap已經有了一個討論的頭緒。
在那之前，您可以閱讀ragibhasan的文章以深入瞭解linux的歷史。
同時，“post-halloween文檔”告訴用戶即將到來的2.6內核有哪些可期待的東西（參閱參考資料中的鏈接）。post-halloween文檔的大部分討論內容是用戶需要註意的主要改變，以及需要更新的係統工具（為了利用它們）。關心這一信息人的主要是那些期望提前瞭解2.6內核中有哪些內容的linux發行商，還有終端用戶，這可以讓他們確定為了能利用新部件是否有需要升級的程序。
kerneljanitors項目保持了（實際上現在還在保持）一個列表，內容是需要修復的較小缺陷和解决方法。這些缺陷解决方法中大部分是由於嚮內核打較大的補丁時需要改動很多部分代碼而導致的，比如有些地方會影響設備驅動程序。那些新近從事內核開發的人開始時的工作可以選擇列表中的條目，這樣讓他們可以通過小項目學習如何編寫內核代碼，同時有機會為社區做出貢獻。
還有，在另一個預發佈的項目中，johncherry追蹤了在對每個已經發佈的內核版本進行編譯時發現的錯誤和警告。這些編譯統計數字隨着時間的流逝一直持續下降，而且，以係統的形式來發佈這些結果使得所取得的進展一目瞭然。在很多情況下，可以像使用kerneljanitors列表一樣來利用這些警告和錯誤消息中的一部分，因為編譯錯誤通常是由小的缺陷引起的，需要一些努力去修復。
最後，還有andrewmorton的“must-fix”列表。由於他已經被選定為2.6內核發佈後的維護者，他運用他的特權概括地列出了那些他認為在最終的2.6內核發佈前最迫切需要解决方案的問題。must-fix列表中包含了內核bugzilla係統中的缺陷，需要完成的部件，以及其他已知的問題，這些問題如不解决將阻礙2.6發佈。這一信息可以幫助指明在新內核發佈前還需要哪些步驟；對那些關心這一萬衆期待的2.6內核發佈何時能完成的人來說，它還可以提供有價值的信息。
自從去年年底2.6內核發佈以後，這些資料中有一些已經明顯不再進行維護了。其他的相關工作在主要版本發佈後仍未結束，還要繼續進行後期的更新。有趣的是能看到哪些又被重新提起，有了哪些革新，我們又一次接近了一個主要發佈版本。
結束語
多數人在考慮內核的一個新的穩定版本時，第一個問題通常是“這一版本中有什麽新東西嗎？”實際上除了一些新特性和修復之外，在幕後還有一個隨着時間而不斷改進的過程。
在linux社區中，開放源代碼開發日益興旺。致力於linux內核和其他方面工作的編碼者之間聯繫是鬆散的，這就使得團隊可以成功地適應變化。在許多方面，相對於已經完成的很多單個的改進和缺陷修復而言，linux的開發和測試方法——尤其是這些方法隨時間的推移得到了改進——對新內核的可靠性影響更為深遠。 |
|
| 從天文學意義上講，一顆行星（或一顆恆星）都有兩個核：內核和外核，星體內核的溫度可高達幾千攝氏度。 |
|
- : inner core
- n.: kernel
|
|
| 單內核模式 | 微內核模式 | cpu | 硬件 | 電腦 | INTEL | amd | duron | | athlon | 64 | 閃竜 | 更多結果... |
|