經(jīng)過為期三年的積極開發(fā)，新2.6Linux內(nèi)核最近已經(jīng)發(fā)布了，在這期間，Linux內(nèi)核的開發(fā)和測試方法發(fā)生了一些有趣的變化。當(dāng)前，開發(fā)內(nèi)核的方法在很多方面與三年前沒什么不同。不過，一些關(guān)鍵變化已經(jīng)使整體的穩(wěn)定性和質(zhì)量得到了提高。

源代碼管理

歷史上，從來沒有出現(xiàn)過用于Linux內(nèi)核的正式的源代碼管理或修正控制系統(tǒng)。實(shí)際上，很多開發(fā)者實(shí)現(xiàn)了他們自己的修正控制器，但是并沒有官方的LinuxCVS檔案庫，讓LinusTorvalds檢查加入代碼，并讓其他人可以由此獲得代碼。修正控制器的缺乏，常常會使發(fā)行版本之間存在“代溝”，沒有人真正知道加入了哪些改變，這些改變是否能很好地融合，或者在即將發(fā)行的版本中哪些新內(nèi)容是值得期待的。通常，如果更多的開發(fā)者可以像了解他們自己所做的改變一樣了解到那些變化，某些問題就可以得到避免。

由于缺乏正式的修正控制器和源代碼管理工具，使得很多人提議使用一個(gè)名為BitKeeper的產(chǎn)品。BitKeeper是一個(gè)源代碼控制管理系統(tǒng)，很多內(nèi)核開發(fā)者已經(jīng)成功地將其應(yīng)用于他們自己的內(nèi)核開發(fā)工作中。最初的2.5內(nèi)核發(fā)布后不久，LinusTorvalds開始試用BitKeeper，以確定它是否能滿足他的需要。現(xiàn)在，主要的2.4和2.5內(nèi)核的Linux內(nèi)核源代碼都是用BitKeeper來管理的。對大部分可能很少或者根本不關(guān)心內(nèi)核開發(fā)的用戶來說，這一點(diǎn)看起來可能無關(guān)緊要。不過，在一些情況下，用戶可以受益于那些由于使用BitKeeper而帶來的開發(fā)Linux內(nèi)核的方法的改變。

使用BitKeeper的最大好處之一是補(bǔ)丁的融合。當(dāng)多個(gè)補(bǔ)丁應(yīng)用于同一基礎(chǔ)的代碼之上，并且其中一些補(bǔ)丁會對同一部分產(chǎn)生影響時(shí)，就可能會出現(xiàn)融合問題。一個(gè)好的源代碼管理系統(tǒng)可以自動地完成其中一些更為復(fù)雜的部分工作，這樣可以更快地融合補(bǔ)丁，并使更多的補(bǔ)丁加入到內(nèi)核中。隨著Linux內(nèi)核開發(fā)者社區(qū)的擴(kuò)大，非常需要修正控制器來幫助保持對所有改變的追蹤。由于每個(gè)人都可以將這些改變集成到主要的Linux內(nèi)核中，為保證補(bǔ)丁不會被遺忘并可以方便地融合和管理，BitKeeper等工具是必不可少的。

非常有必要使用一個(gè)實(shí)時(shí)的、集中的檔案庫來保存對Linux內(nèi)核的最新更新。每一個(gè)被內(nèi)核接受的改變或者補(bǔ)丁都被作為一個(gè)改變集被追蹤。終端用戶和開發(fā)者可以保存他們自己的源文件檔案庫，并根據(jù)需要可以通過一個(gè)簡單的命令用最新的改變集進(jìn)行更新。對開發(fā)者來說，這意味著可以始終使用最新的代碼拷貝。測試人員可以使用這些邏輯的改變集合來確定哪些變化導(dǎo)致了問題的產(chǎn)生，縮短調(diào)試所需要的時(shí)間。甚至那些希望使用最新內(nèi)核的用戶也可以直接利用實(shí)時(shí)的、集中的檔案庫，因?yàn)楝F(xiàn)在一旦他們所需要的部件或缺陷修復(fù)加入到內(nèi)核中，他們就可以馬上進(jìn)行更新。當(dāng)代碼融合到內(nèi)核時(shí)，任何用戶都可以提供關(guān)于這些代碼的即時(shí)反饋和缺陷報(bào)告。

并行開發(fā)

隨著Linux內(nèi)核的成長，變得更加復(fù)雜，而且吸引更多開發(fā)者將注意力集中到內(nèi)核的特定方面的專門開發(fā)上來，出現(xiàn)了另一個(gè)開發(fā)Linux方法的有趣改變。在2.3內(nèi)核版本的開發(fā)期間，除了由LinusTorvalds發(fā)行的主要的一個(gè)內(nèi)核樹之外，還有一些其他的內(nèi)核樹。

在2.5的開發(fā)期間，內(nèi)核樹出現(xiàn)了爆炸式的增長。由于使用源代碼管理工具可以保持開發(fā)的同步并行進(jìn)行，這樣就可能實(shí)現(xiàn)開發(fā)的部分并行化。為了讓其他人在他們所做的改變被接受之前可以進(jìn)行測試，有一些開發(fā)需要并行化。那些保持自己的樹的內(nèi)核維護(hù)者致力于特定的組件和目標(biāo)，比如內(nèi)存管理、NUMA部件、改進(jìn)擴(kuò)展性和用于特定體系結(jié)構(gòu)的代碼，還有一些樹收集并追蹤對許多小缺陷的糾正。

這種并行開發(fā)模型的優(yōu)點(diǎn)是，它使得需要進(jìn)行重大改變的開發(fā)者，或者針對一個(gè)特定的目標(biāo)進(jìn)行大量類似改變的那些開發(fā)者可以自由地在一個(gè)受控環(huán)境中開發(fā)，而并不影響其他人所用內(nèi)核的穩(wěn)定性。當(dāng)開發(fā)者完成工作后，他們可以發(fā)布針對Linux內(nèi)核當(dāng)前版本的補(bǔ)丁，以實(shí)現(xiàn)到此為止他們所完成的改變。這樣，社區(qū)中的測試人員就可以方便地測試這些改變并提供反饋。當(dāng)每一部分都被證明是穩(wěn)定的之后，那些部分可以單獨(dú)地，或者甚至同時(shí)全部地，融合到主要Linux內(nèi)核中。

在實(shí)際應(yīng)用中測試

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

然而實(shí)際上，內(nèi)核有很多復(fù)雜的相互聯(lián)系。即使進(jìn)行了足夠力度的審查，還是會漏過很多嚴(yán)重的缺陷。此外，最新的內(nèi)核一經(jīng)發(fā)布，終端用戶可以（也經(jīng)常是）下載并使用。2.4.0發(fā)布時(shí)，社區(qū)中很多人都提議進(jìn)行更有組織的測試，以保證特定測試和代碼審查的強(qiáng)度。有組織的測試包括運(yùn)用測試計(jì)劃、測試過程中的可重復(fù)性等等。使用所有的三種方法比最初只使用兩種方法會帶來更高的代碼質(zhì)量。

Linux測試項(xiàng)目

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

代碼覆蓋分析

現(xiàn)在所使用的新工具為內(nèi)核提供了代碼覆蓋分析的功能。覆蓋分析告訴我們，在一個(gè)給定的測試運(yùn)行時(shí)，內(nèi)核中哪些行代碼被執(zhí)行。更重要的是，覆蓋分析提示了內(nèi)核的哪些部分還根本沒有被測試到。這個(gè)數(shù)據(jù)是重要的，因?yàn)樗赋隽诵枰倬帉懩男┬聹y試來測試內(nèi)核的那些部分，以使內(nèi)核可以得到更完備的測試。

持續(xù)多日的內(nèi)核回歸測試

在2.5的開發(fā)周期中，Linux測試項(xiàng)目所采用的另一個(gè)項(xiàng)目是，用LTP測試套件對Linux內(nèi)核執(zhí)行持續(xù)多日的回歸測試。人們用BitKeeper創(chuàng)建了一個(gè)實(shí)時(shí)的、集中的檔案庫，以隨時(shí)可以獲得Linux內(nèi)核的快照。在沒有使用BitKeeper和快照時(shí)，測試人員不得不等到內(nèi)核發(fā)布后才可以開始測試。現(xiàn)在，內(nèi)核只要發(fā)生了改變，測試人員就可以進(jìn)行測試。

使用自動化工具來執(zhí)行持續(xù)多日的回歸測試的另一個(gè)優(yōu)點(diǎn)是，和上一次測試相比變化較小。如果發(fā)現(xiàn)了一個(gè)新的回歸缺陷，通常會容易地檢測出這個(gè)缺陷可能是哪個(gè)改變導(dǎo)致的。

同樣，由于是最新的改變，因此它在開發(fā)者的腦海中印象還比較深——希望這能讓他們更容易地記起并修訂相應(yīng)的代碼。或許Linus法則應(yīng)該有這樣一個(gè)結(jié)論，有一些缺陷比其他缺陷更容易被發(fā)現(xiàn)，因?yàn)槟切┱浅掷m(xù)多日的內(nèi)核回歸測試所發(fā)現(xiàn)并處理的那些。在開發(fā)周期中和實(shí)際發(fā)布之前能夠每天進(jìn)行這些測試，這就使那些只關(guān)注完整發(fā)行版本的測試者可以將精力集中于更嚴(yán)重和耗時(shí)的缺陷。

可擴(kuò)展測試平臺

另外一個(gè)名為開放源代碼開發(fā)實(shí)驗(yàn)室(OpenSourceDevelopmentLabs,OSDL)的團(tuán)隊(duì)也為Linux測試做出了重要的貢獻(xiàn)。2.4內(nèi)核發(fā)布后不久，OSDL創(chuàng)建了一個(gè)叫做可擴(kuò)展測試平臺(ScalableTestPlatform，STP)的系統(tǒng)。STP是一個(gè)自動化的測試平臺，讓開發(fā)者和測試者可以運(yùn)行OSDL硬件之上的系統(tǒng)所提供的測試。開發(fā)者甚至可以使用這個(gè)系統(tǒng)來測試他們自己的針對內(nèi)核的補(bǔ)丁。可擴(kuò)展測試平臺簡化了測試的步驟，因?yàn)镾TP可以構(gòu)建內(nèi)核、設(shè)置測試、運(yùn)行測試，并收集結(jié)果。然后得到結(jié)果以進(jìn)行深入地比較。很多人無法接觸大型系統(tǒng)，比如具有8個(gè)處理器的SMP機(jī)器，而通過STP，任何人都可以在像這樣的大型系統(tǒng)上運(yùn)行測試，這個(gè)系統(tǒng)(STP)的另一個(gè)好處就在于此。

追蹤缺陷

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

現(xiàn)在，OSDL安裝了一個(gè)缺陷追蹤系統(tǒng)（請參閱參考資料中的鏈接），來報(bào)告和追蹤Linux內(nèi)核的缺陷。系統(tǒng)經(jīng)過了配置，這樣當(dāng)某個(gè)組件的缺陷被報(bào)告時(shí)，那個(gè)組件的維護(hù)者就會得到通知。維護(hù)者既可以接受并修復(fù)那個(gè)缺陷，或重新指定缺陷（如果最終確定實(shí)際上那是內(nèi)核另外一部分的缺陷），也可以排除它（如果最終確定并不是真正的缺陷，比如錯(cuò)誤配置的系統(tǒng)）。報(bào)告給郵件列表的缺陷還有丟失的危險(xiǎn)，因?yàn)樵絹碓蕉嗟碾娮余]件涌向那個(gè)列表。然而，在缺陷追蹤系統(tǒng)中，始終有對每一個(gè)缺陷及其當(dāng)前狀態(tài)的記錄。

大量信息

在為將來的2.6Linux內(nèi)核進(jìn)行開的過程中，除了這些自動化的信息管理方法之外，開放源代碼社區(qū)的不同成員還收集和追蹤了數(shù)量驚人的信息。

例如，在KernelNewbies站點(diǎn)上創(chuàng)建了一個(gè)狀態(tài)列表，來保持對已經(jīng)提出的內(nèi)核新部件的追蹤。這個(gè)列表包含了以狀態(tài)排序的條目，如果它們已經(jīng)完成了，則說明它們已經(jīng)包含在哪個(gè)內(nèi)核中，如果還沒有完成，則指出還需要多長時(shí)間。列表上很多條目的鏈接指向大型項(xiàng)目的Web站點(diǎn)，或者當(dāng)條目較小時(shí)，鏈接指向一個(gè)解釋相應(yīng)部件的電子郵件信息的拷貝。

同時(shí),“post-halloween文檔”告訴用戶即將到來的2.6內(nèi)核有哪些可期待的東西（參閱參考資料中的鏈接）。post-halloween文檔的大部分討論內(nèi)容是用戶需要注意的主要改變，以及需要更新的系統(tǒng)工具（為了利用它們）。關(guān)心這一信息人的主要是那些期望提前了解2.6內(nèi)核中有哪些內(nèi)容的Linux發(fā)行商，還有終端用戶，這可以讓他們確定為了能利用新部件是否有需要升級的程序。

KernelJanitors項(xiàng)目保持了（實(shí)際上現(xiàn)在還在保持）一個(gè)列表，內(nèi)容是需要修復(fù)的較小缺陷和解決方法。這些缺陷解決方法中大部分是由于向內(nèi)核打較大的補(bǔ)丁時(shí)需要改動很多部分代碼而導(dǎo)致的，比如有些地方會影響設(shè)備驅(qū)動程序。那些新近從事內(nèi)核開發(fā)的人開始時(shí)的工作可以選擇列表中的條目，這樣讓他們可以通過小項(xiàng)目學(xué)習(xí)如何編寫內(nèi)核代碼，同時(shí)有機(jī)會為社區(qū)做出貢獻(xiàn)。

還有，在另一個(gè)預(yù)發(fā)布的項(xiàng)目中，JohnCherry追蹤了在對每個(gè)已經(jīng)發(fā)布的內(nèi)核版本進(jìn)行編譯時(shí)發(fā)現(xiàn)的錯(cuò)誤和警告。這些編譯統(tǒng)計(jì)數(shù)字隨著時(shí)間的流逝一直持續(xù)下降，而且，以系統(tǒng)的形式來發(fā)布這些結(jié)果使得所取得的進(jìn)展一目了然。在很多情況下，可以像使用KernelJanitors列表一樣來利用這些警告和錯(cuò)誤消息中的一部分，因?yàn)榫幾g錯(cuò)誤通常是由小的缺陷引起的，需要一些努力去修復(fù)。

最后，還有AndrewMorton的“must-fix”列表。由于他已經(jīng)被選定為2.6內(nèi)核發(fā)布后的維護(hù)者，他運(yùn)用他的特權(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ā)布何時(shí)能完成的人來說，它還可以提供有價(jià)值的信息。

自從去年年底2.6內(nèi)核發(fā)布以后，這些資料中有一些已經(jīng)明顯不再進(jìn)行維護(hù)了。其他的相關(guān)工作在主要版本發(fā)布后仍未結(jié)束，還要繼續(xù)進(jìn)行后期的更新。有趣的是能看到哪些又被重新提起，有了哪些革新，我們又一次接近了一個(gè)主要發(fā)布版本。

結(jié)束語

多數(shù)人在考慮內(nèi)核的一個(gè)新的穩(wěn)定版本時(shí)，第一個(gè)問題通常是“這一版本中有什么新東西嗎？”實(shí)際上除了一些新特性和修復(fù)之外，在幕后還有一個(gè)隨著時(shí)間而不斷改進(jìn)的過程。

在Linux社區(qū)中,開放源代碼開發(fā)日益興旺。致力于Linux內(nèi)核和其他方面工作的編碼者之間聯(lián)系是松散的，這就使得團(tuán)隊(duì)可以成功地適應(yīng)變化。在許多方面，相對于已經(jīng)完成的很多單個(gè)的改進(jìn)和缺陷修復(fù)而言，Linux的開發(fā)和測試方法——尤其是這些方法隨時(shí)間的推移得到了改進(jìn)——對新內(nèi)核的可靠性影響更為深遠(yuǎn).