內(nèi)核體系結(jié)構(gòu)內(nèi)核，是一個操作系統(tǒng)的核心。是基于硬件的第一層軟件擴充，提供操作系統(tǒng)的最基本的功能，是操作系統(tǒng)工作的基礎(chǔ)，它負(fù)責(zé)管理系統(tǒng)的進程、內(nèi)存、設(shè)備驅(qū)動程序、文件和網(wǎng)絡(luò)系統(tǒng)，決定著系統(tǒng)的性能和穩(wěn)定性。[2]
現(xiàn)代操作系統(tǒng)設(shè)計中，為減少系統(tǒng)本身的開銷，往往將一些與硬件緊密相關(guān)的（如中斷處理程序、設(shè)備驅(qū)動程序等）、基本的、公共的、運行頻率較高的模塊（如時鐘管理、進程調(diào)度等）以及關(guān)鍵性數(shù)據(jù)結(jié)構(gòu)獨立開來，使之常駐內(nèi)存，并對他們進行保護。通常把這一部分稱之為操作系統(tǒng)的內(nèi)核。
程序可以直接地被調(diào)入計算機中執(zhí)行，這樣的設(shè)計說明了設(shè)計者不希望提供任何硬件抽象和操作系統(tǒng)的支持，它常見于早期計算機系統(tǒng)的設(shè)計中。最終，一些輔助性程序，例如程序加載器和調(diào)試器，被設(shè)計到機器核心當(dāng)中，或者固化在只讀存儲器里。這些變化發(fā)生時，操作系統(tǒng)內(nèi)核的概念就漸漸明晰起來了。
內(nèi)核Linux的第一個公開版本是1991年10月的0.02版本，兩個月以后，在1991年12月，Linux發(fā)布了0.11版本，這是第一個可以不依賴于Minix就可以使用的獨立內(nèi)核。
0.12版本發(fā)布一個月以后，在3月，版本號跳到了0.95，反映出系統(tǒng)正變得成熟，不僅如此，直到兩年后，也就是1994年3月，具有里程碑意義的1.0.0才完成。
大約從這時起開始使用兩“路”編號方法標(biāo)注內(nèi)核的開發(fā)，偶數(shù)號的內(nèi)核（比如1.0、2.2、2.4、2.6）是穩(wěn)定的，“產(chǎn)品”型號，同時，奇數(shù)號的內(nèi)核版本（1.1、2.3）是前沿的或者“發(fā)展中的”內(nèi)核。一個穩(wěn)定的內(nèi)核發(fā)布以后幾個月就開始新內(nèi)核的開發(fā)工作。然而，2.5的開發(fā)工作是在2.4完成后幾十個月以后才開始的。
post-halloween文檔的大部分討論內(nèi)容是用戶需要注意的主要改變，以及需要更新的系統(tǒng)工具（為了利用它們）。關(guān)心這一信息人的主要是那些期望提前了解2.6內(nèi)核中有哪些內(nèi)容的Linux發(fā)行商，還有終端用戶，這可以讓他們確定為了能利用新部件是否有需要升級的程序。
KernelJanitors項目保持了一個列表，內(nèi)容是需要修復(fù)的較小缺陷和解決方法。這些缺陷解決方法中大部分是由于向內(nèi)核打較大的補丁時需要改動很多部分代碼而導(dǎo)致的，比如有些地方會影響設(shè)備驅(qū)動程序。那些新近從事內(nèi)核開發(fā)的人開始時的工作可以選擇列表中的條目，這樣讓他們可以通過小項目學(xué)習(xí)如何編寫內(nèi)核代碼，同時有機會為社區(qū)做出貢獻。
還有，在另一個預(yù)發(fā)布的項目中，JohnCherry追蹤了在對每個已經(jīng)發(fā)布的內(nèi)核版本進行編譯時發(fā)現(xiàn)的錯誤和警告。這些編譯統(tǒng)計數(shù)字隨著時間的流逝一直持續(xù)下降，而且，以系統(tǒng)的形式來發(fā)布這些結(jié)果使得所取得的進展一目了然。在很多情況下，可以像使用KernelJanitors列表一樣來利用這些警告和錯誤消息中的一部分，因為編譯錯誤通常是由小的缺陷引起的，需要一些努力去修復(fù)。
最后，還有AndrewMorton的“must-fix”列表。由于他已經(jīng)被選定為2.6內(nèi)核發(fā)布后的維護者，他運用他的特權(quán)概括地列出了那些他認(rèn)為在最終的2.6內(nèi)核發(fā)布前最迫切需要解決方案的問題。must-fix列表中包含了內(nèi)核Bugzilla系統(tǒng)中的缺陷，需要完成的部件，以及其他已知的問題，這些問題如不解決將阻礙2.6發(fā)布。這一信息可以幫助指明在新內(nèi)核發(fā)布前還需要哪些步驟；對那些關(guān)心這一萬眾期待的2.6內(nèi)核發(fā)布何時能完成的人來說，它還可以提供有價值的信息。[3]
單內(nèi)核操作系統(tǒng)單內(nèi)核（Monolithic kernel），是個很大的進程。它的內(nèi)部又能夠被分為若干模塊（或是層次或其他）。但是在運行的時候，它是個單獨的二進制大映象。其模塊間的通訊是通過直接調(diào)用其他模塊中的函數(shù)實現(xiàn)的，而不是消息傳遞。
單內(nèi)核結(jié)構(gòu)在硬件之上定義了一個高階的抽象界面，應(yīng)用一組原語(或者叫系統(tǒng)調(diào)用)來實現(xiàn)操作系統(tǒng)的功能，例如進程管理，文件系統(tǒng)，和存儲管理等等，這些功能由多個運行在核心態(tài)的模塊來完成。
盡管每一個模塊都是單獨地服務(wù)這些操作，內(nèi)核代碼是高度集成的，而且難以編寫正確。因為所有的模塊都在同一個內(nèi)核空間上運行，一個很小的bug都會使整個系統(tǒng)崩潰。然而，如果開發(fā)順利，單內(nèi)核結(jié)構(gòu)就可以從運行效率上得到好處。
很多現(xiàn)代的單內(nèi)核結(jié)構(gòu)內(nèi)核，如Linux和FreeBSD內(nèi)核，能夠在運行時將模塊調(diào)入執(zhí)行，這就可以使擴充內(nèi)核的功能變得更簡單，也可以使內(nèi)核的核心部分變得更簡潔。
單內(nèi)核結(jié)構(gòu)是非常有吸引力的一種設(shè)計，由于在同一個地址空間上實現(xiàn)所有低級操作的系統(tǒng)控制代碼的復(fù)雜性的效率會比在不同地址空間上實現(xiàn)更高些。 單核結(jié)構(gòu)正趨向于容易被正確設(shè)計，所以它的發(fā)展會比微內(nèi)核結(jié)構(gòu)更迅速些。
單內(nèi)核結(jié)構(gòu)的例子：傳統(tǒng)的UNIX內(nèi)核----例如伯克利大學(xué)發(fā)行的版本，Linux內(nèi)核。
微內(nèi)核微內(nèi)核（Microkernelkernel）結(jié)構(gòu)由一個非常簡單的硬件抽象層和一組比較關(guān)鍵的原語或系統(tǒng)調(diào)用組成，這些原語僅僅包括了建立一個系統(tǒng)必需的幾個部分，如線程管理，地址空間和進程間通信等。
微核的目標(biāo)是將系統(tǒng)服務(wù)的實現(xiàn)和系統(tǒng)的基本操作規(guī)則分離開來。例如，進程的輸入/輸出鎖定服務(wù)可以由運行在微核之外的一個服務(wù)組件來提供。這些非常模塊化的用戶態(tài)服務(wù)器用于完成操作系統(tǒng)中比較高級的操作，這樣的設(shè)計使內(nèi)核中最核心的部分的設(shè)計更簡單。一個服務(wù)組件的失效并不會導(dǎo)致整個系統(tǒng)的崩潰，內(nèi)核需要做的，僅僅是重新啟動這個組件，而不必影響其它的部分。
微內(nèi)核將許多OS服務(wù)放入分離的進程，如文件系統(tǒng),設(shè)備驅(qū)動程序,而進程通過消息傳遞調(diào)用OS服務(wù)。微內(nèi)核結(jié)構(gòu)必然是多線程的,第一代微內(nèi)核,在核心提供了較多的服務(wù),因此被稱為'胖微內(nèi)核',它的典型代表是MACH。它既是GNU HURD也是APPLE SERVER OS的核心，可以說,蒸蒸日上.第二代為微內(nèi)核只提供最基本的OS服務(wù),典型的OS是QNX,QNX在理論界很有名,被認(rèn)為是一種先進的OS。
微內(nèi)核只提供了很小一部分的硬件抽象，大部分功能由一種特殊的用戶態(tài)程序：服務(wù)器來完成。微核經(jīng)常被用于機器人和醫(yī)療器械的嵌入式設(shè)計中，因為它的系統(tǒng)的關(guān)鍵部分都處在相互分開的，被保護的存儲空間中。這對于單核設(shè)計來說是不可能的，就算它采用了運行時加載模塊的方式。
微內(nèi)核的例子：AIX，BeOS，L4微內(nèi)核系列，.Mach中用于GNU Hurd和Mac OS X，Minix，MorphOS，QNX，RadiOS，VSTa。
外內(nèi)核外內(nèi)核系統(tǒng)，也被稱為縱向結(jié)構(gòu)操作系統(tǒng)，是一種比較極端的設(shè)計方法。
外內(nèi)核這種內(nèi)核不提供任何硬件抽象操作，但是允許為內(nèi)核增加額外的運行庫，通過這些運行庫應(yīng)用程序可以直接地或者接近直接地對硬件進行操作。
它的設(shè)計理念是讓用戶程序的設(shè)計者來決定硬件接口的設(shè)計。外內(nèi)核本身非常的小，它通常只負(fù)責(zé)系統(tǒng)保護和系統(tǒng)資源復(fù)用相關(guān)的服務(wù)。
傳統(tǒng)的內(nèi)核設(shè)計(包括單核和微核)都對硬件作了抽象，把硬件資源或設(shè)備驅(qū)動程序都隱藏在硬件抽象層下。比方說，在這些系統(tǒng)中，如果分配一段物理存儲，應(yīng)用程序并不知道它的實際位置。
而外核的目標(biāo)就是讓應(yīng)用程序直接請求一塊特定的物理空間，一塊特定的磁盤塊等等。系統(tǒng)本身只保證被請求的資源當(dāng)前是空閑的，應(yīng)用程序就允許直接存取它。既然外核系統(tǒng)只提供了比較低級的硬件操作，而沒有像其他系統(tǒng)一樣提供高級的硬件抽象，那么就需要增加額外的運行庫支持。這些運行庫運行在外核之上，給用戶程序提供了完整的功能。
理論上，這種設(shè)計可以讓各種操作系統(tǒng)運行在一個外核之上，如Windows和Unix。并且設(shè)計人員可以根據(jù)運行效率調(diào)整系統(tǒng)的各部分功能。
外核設(shè)計還停留在研究階段，沒有任何一個商業(yè)系統(tǒng)采用了這種設(shè)計。幾種概念上的操作系統(tǒng)正在被開發(fā)，如劍橋大學(xué)的Nemesis，格拉斯哥大學(xué)的Citrix系統(tǒng)和瑞士計算機科學(xué)院的一套系統(tǒng)。麻省理工學(xué)院也在進行著這類研究。
混合內(nèi)核混合內(nèi)核它很像微內(nèi)核結(jié)構(gòu)，只不過它的的組件更多的在核心態(tài)中運行，以獲得更快的執(zhí)行速度。
混合內(nèi)核實質(zhì)上是微內(nèi)核，只不過它讓一些微核結(jié)構(gòu)運行在用戶空間的代碼運行在內(nèi)核空間，這樣讓內(nèi)核的運行效率更高些。這是一種妥協(xié)做法，設(shè)計者參考了微內(nèi)核結(jié)構(gòu)的系統(tǒng)運行速度不佳的理論。然而后來的實驗證明，純微內(nèi)核的系統(tǒng)實際上也可以是高效率的。大多數(shù)現(xiàn)代操作系統(tǒng)遵循這種設(shè)計范疇，微軟公司開發(fā)的Windows操作系統(tǒng)就是一個很好的例子。另外還有XNU，運行在蘋果Mac OS X上的內(nèi)核，也是一個混合內(nèi)核。
混合內(nèi)核的例子： BeOS 內(nèi)核 ，DragonFly BSD，ReactOS 內(nèi)核
Windows NT、Windows 2000、Windows XP、Windows Server 2003以及Windows Vista等基于NT技術(shù)的操作系統(tǒng)。
抽象隱藏
內(nèi)核提供一種硬件抽象的方法來完成對硬件操作，因為這些操作是非常復(fù)雜的，硬件抽象隱藏了復(fù)雜性，為應(yīng)用軟件和硬件提供了一套簡潔，統(tǒng)一的接口，使程序設(shè)計更為簡單。
源代碼管理
歷史上，從來沒有出現(xiàn)過用于Linux內(nèi)核的正式的源代碼管理或修正控制系統(tǒng)。實際上，很多開發(fā)者實現(xiàn)了他們自己的修正控制器，但是并沒有官方的LinuxCVS檔案庫，讓LinusTorvalds檢查加入代碼，并讓其他人可以由此獲得代碼。修正控制器的缺乏，常常會使發(fā)行版本之間存在“代溝”，沒有人真正知道加入了哪些改變，這些改變是否能很好地融合，或者在發(fā)行的版本中哪些新內(nèi)容是值得期待的。通常，如果更多的開發(fā)者可以像了解他們自己所做的改變一樣了解到那些變化，某些問題就可以得到避免。
非常有必要使用一個實時的、集中的檔案庫來保存對Linux內(nèi)核的最新更新。每一個被內(nèi)核接受的改變或者補丁都被作為一個改變集被追蹤。終端用戶和開發(fā)者可以保存他們自己的源文件檔案庫，并根據(jù)需要可以通過一個簡單的命令用最新的改變集進行更新。對開發(fā)者來說，這意味著可以始終使用最新的代碼拷貝。測試人員可以使用這些邏輯的改變集合來確定哪些變化導(dǎo)致了問題的產(chǎn)生，縮短調(diào)試所需要的時間。甚至那些希望使用最新內(nèi)核的用戶也可以直接利用實時的、集中的檔案庫，因為一旦他們所需要的部件或缺陷修復(fù)加入到內(nèi)核中，他們就可以馬上進行更新。當(dāng)代碼融合到內(nèi)核時，任何用戶都可以提供關(guān)于這些代碼的即時反饋和缺陷報告。
并行開發(fā)
隨著Linux內(nèi)核的成長，變得更加復(fù)雜，而且吸引更多開發(fā)者將注意力集中到內(nèi)核的特定方面的專門開發(fā)上來，出現(xiàn)了另一個開發(fā)Linux方法的有趣改變。在2.3內(nèi)核版本的開發(fā)期間，除了由LinusTorvalds發(fā)行的主要的一個內(nèi)核樹之外，還有一些其他的內(nèi)核樹。
在2.5的開發(fā)期間，內(nèi)核樹出現(xiàn)了爆炸式的增長。由于使用源代碼管理工具可以保持開發(fā)的同步并行進行，這樣就可能實現(xiàn)開發(fā)的部分并行化。為了讓其他人在他們所做的改變被接受之前可以進行測試，有一些開發(fā)需要并行化。那些保持自己的樹的內(nèi)核維護者致力于特定的組件和目標(biāo)，比如內(nèi)存管理、NUMA部件、改進擴展性和用于特定體系結(jié)構(gòu)的代碼，還有一些樹收集并追蹤對許多小缺陷的糾正。
這種并行開發(fā)模型的優(yōu)點是，它使得需要進行重大改變的開發(fā)者，或者針對一個特定的目標(biāo)進行大量類似改變的那些開發(fā)者可以自由地在一個受控環(huán)境中開發(fā)，而并不影響其他人所用內(nèi)核的穩(wěn)定性。當(dāng)開發(fā)者完成工作后，他們可以發(fā)布針對Linux內(nèi)核當(dāng)前版本的補丁，以實現(xiàn)到此為止他們所完成的改變。這樣，社區(qū)中的測試人員就可以方便地測試這些改變并提供反饋。當(dāng)每一部分都被證明是穩(wěn)定的之后，那些部分可以單獨地，或者甚至同時全部地，融合到主要Linux內(nèi)核中。
代碼覆蓋分析
新工具為內(nèi)核提供了代碼覆蓋分析的功能。覆蓋分析表明，在一個給定的測試運行時，內(nèi)核中哪些行代碼被執(zhí)行。更重要的是，覆蓋分析提示了內(nèi)核的哪些部分還根本沒有被測試到。這個數(shù)據(jù)是重要的，因為它指出了需要再編寫哪些新測試來測試內(nèi)核的那些部分，以使內(nèi)核可以得到更完備的測試。
大量信息
在為將來的2.6Linux內(nèi)核進行開的過程中，除了這些自動化的信息管理方法之外，開放源代碼社區(qū)的不同成員還收集和追蹤了數(shù)量驚人的信息。
例如，在KernelNewbies站點上創(chuàng)建了一個狀態(tài)列表，來保持對已經(jīng)提出的內(nèi)核新部件的追蹤。這個列表包含了以狀態(tài)排序的條目，如果它們已經(jīng)完成了，則說明它們已經(jīng)包含在哪個內(nèi)核中，如果還沒有完成，則指出還需要多長時間。列表上很多條目的鏈接指向大型項目的Web站點，或者當(dāng)條目較小時，鏈接指向一個解釋相應(yīng)部件的電子郵件信息的拷貝。
單內(nèi)核與微內(nèi)核的比較單內(nèi)核與微內(nèi)核的比較
單內(nèi)核結(jié)構(gòu)是非常有吸引力的一種設(shè)計，由于在同一個地址空間上實現(xiàn)所有復(fù)雜的低階操作系統(tǒng)控制代碼的效率會比在不同地址空間上實現(xiàn)更高些。
20世紀(jì)90年代初，單內(nèi)核結(jié)構(gòu)被認(rèn)為是過時的。把Linux設(shè)計成為單內(nèi)核結(jié)構(gòu)而不是微內(nèi)核，引起了無數(shù)的爭議(參見塔能鮑姆-林納斯辯論)。
現(xiàn)在，單核結(jié)構(gòu)正傾向于設(shè)計不容易出錯，所以它的發(fā)展會比微內(nèi)核結(jié)構(gòu)更迅速些。兩個陣營中都有成功的案例。微核經(jīng)常被用于機器人和醫(yī)療器械的嵌入式設(shè)計中，因為它的系統(tǒng)的關(guān)鍵部分都處在相互分開的，被保護的存儲空間中。這對于單核設(shè)計來說是不可能的，就算它采用了運行時加載模塊的方式。
盡管Mach是眾所周知的多用途的微內(nèi)核，人們還是開發(fā)了除此之外的幾個微內(nèi)核。L3是一個演示性的內(nèi)核，只是為了證明微內(nèi)核設(shè)計并不總是低運行速度。它的后續(xù)版本L4，甚至可以將Linux內(nèi)核作為它的一個進程，運行在單獨的地址空間。
QNX是一個從20世紀(jì)80年代，就開始設(shè)計的微內(nèi)核系統(tǒng)。它比Mach更接近微內(nèi)核的理念。它被用于一些特殊的領(lǐng)域；在這些情況下，由于軟件錯誤，導(dǎo)致系統(tǒng)失效是不允許的。例如航天飛機上的機械手，還有研磨望遠(yuǎn)鏡鏡片的機器，一點點失誤就會導(dǎo)致上千美元的損失。
很多人相信，由于Mach不能夠解決一些提出微內(nèi)核理論時針對的問題，所以微內(nèi)核技術(shù)毫無用處。Mach的愛好者表明這是非常狹隘的觀點，遺憾的是似乎所有人都開始接受這種觀點。
測試背景
過去，Linux內(nèi)核測試方法圍繞開放源代碼開發(fā)模型進行。由于代碼一經(jīng)發(fā)布后就公開給其他開發(fā)者進行審查，因此從來沒有出現(xiàn)過一個與其他形式的軟件開發(fā)類似的正式的驗證周期。這種方法背后的理論依據(jù)是“TheCathedralandtheBazaar”中所謂的“Linus法則”（請查閱參考資料以獲得相關(guān)的參考），這一法則的內(nèi)容為“眾人的眼光是雪亮的”。換句話說，高力度的審查可以找出大部分真正的大問題。
然而實際上，內(nèi)核有很多復(fù)雜的相互聯(lián)系。即使進行了足夠力度的審查，還是會漏過很多嚴(yán)重的缺陷。此外，最新的內(nèi)核一經(jīng)發(fā)布，終端用戶可以（也經(jīng)常是）下載并使用。2.4.0發(fā)布時，社區(qū)中很多人都提議進行更有組織的測試，以保證特定測試和代碼審查的強度。有組織的測試包括運用測試計劃、測試過程中的可重復(fù)性等等。使用所有的三種方法比最初只使用兩種方法會帶來更高的代碼質(zhì)量。
測試項目
最早對Linux開始進行有組織測試的貢獻者是Linux測試項目(LinuxTestProject，LTP)。這個項目的目的是通過更有組織的測試方法提高Linux的質(zhì)量。這個測試項目的一部分是自動測試套件的開發(fā)。LTP開發(fā)的主要測試套件也叫做Linux測試項目。2.4.0內(nèi)核發(fā)布時，LTP測試套件只有大約100個測試。隨著2.4和2.5版本Linux的發(fā)展與成熟，LTP測試套件也正在發(fā)展和成熟。當(dāng)前，Linux測試項目包括超過2000個測試，而且這個數(shù)字還在增長。
在2.5的開發(fā)周期中，Linux測試項目所采用的另一個項目是，用LTP測試套件對Linux內(nèi)核執(zhí)行持續(xù)多日的回歸測試。人們用BitKeeper創(chuàng)建了一個實時的、集中的檔案庫，以隨時可以獲得Linux內(nèi)核的快照。在沒有使用BitKeeper和快照時，測試人員不得不等到內(nèi)核發(fā)布后才可以開始測試。內(nèi)核只要發(fā)生了改變，測試人員就可以進行測試。
使用自動化工具來執(zhí)行持續(xù)多日的回歸測試的另一個優(yōu)點是，和上一次測試相比變化較小。如果發(fā)現(xiàn)了一個新的回歸缺陷，通常會容易地檢測出這個缺陷可能是哪個改變導(dǎo)致的。
同樣，由于是最新的改變，因此它在開發(fā)者的腦海中印象還比較深——希望這能讓他們更容易地記起并修訂相應(yīng)的代碼。或許Linus法則應(yīng)該有這樣一個結(jié)論，有一些缺陷比其他缺陷更容易被發(fā)現(xiàn)，因為那些正是持續(xù)多日的內(nèi)核回歸測試所發(fā)現(xiàn)并處理的那些。在開發(fā)周期中和實際發(fā)布之前能夠每天進行這些測試，這就使那些只關(guān)注完整發(fā)行版本的測試者可以將精力集中于更嚴(yán)重和耗時的缺陷。
另外一個名為開放源代碼開發(fā)實驗室(OpenSourceDevelopmentLabs,OSDL)的團隊也為Linux測試做出了重要的貢獻。2.4內(nèi)核發(fā)布后不久，OSDL創(chuàng)建了一個叫做可擴展測試平臺(ScalableTestPlatform，STP)的系統(tǒng)。STP是一個自動化的測試平臺，讓開發(fā)者和測試者可以運行OSDL硬件之上的系統(tǒng)所提供的測試。開發(fā)者甚至可以使用這個系統(tǒng)來測試他們自己的針對內(nèi)核的補丁?？蓴U展測試平臺簡化了測試的步驟，因為STP可以構(gòu)建內(nèi)核、設(shè)置測試、運行測試，并收集結(jié)果。然后得到結(jié)果以進行深入地比較。很多人無法接觸大型系統(tǒng)，比如具有8個處理器的SMP機器，而通過STP，任何人都可以在像這樣的大型系統(tǒng)上運行測試，這個系統(tǒng)(STP)的另一個好處就在于此。
自從2.4發(fā)布以來，對Linux內(nèi)核的有組織測試最大的改進之一是缺陷追蹤。過去，在Linux內(nèi)核中發(fā)現(xiàn)的缺陷會報告給Linux內(nèi)核郵件列表，報告給特定組件或者特定體系的郵件列表，或者直接報告給維護發(fā)現(xiàn)缺陷的那部分代碼的個人。隨著開發(fā)和測試Linux的人數(shù)的增加，這個系統(tǒng)的不足之處很快就暴露了出來。在以前，除非人們對缺陷的報告可以驚人地維持下去，缺陷經(jīng)常被遺漏、遺忘或者忽略。
OSDL安裝了一個缺陷追蹤系統(tǒng)，來報告和追蹤Linux內(nèi)核的缺陷。系統(tǒng)經(jīng)過了配置，這樣當(dāng)某個組件的缺陷被報告時，那個組件的維護者就會得到通知。維護者既可以接受并修復(fù)那個缺陷，或重新指定缺陷（如果最終確定實際上那是內(nèi)核另外一部分的缺陷），也可以排除它（如果最終確定并不是真正的缺陷，比如錯誤配置的系統(tǒng)）。報告給郵件列表的缺陷還有丟失的危險，因為越來越多的電子郵件涌向那個列表。然而，在缺陷追蹤系統(tǒng)中，始終有對每一個缺陷及其當(dāng)前狀態(tài)的記錄。
聯(lián)系客服
