| 作者：Paul Larson 發文時間：2004.04.20 |
 |
| 期待已久的 2.6 內核終於到來了。IBM Linux Technology Center 的 Paul Larson 暗中關注那些讓 2.6 成爲有史以來最好內核的工具、測試和技術 —— 從修正控制和迴歸測試到缺陷追蹤和列表保持。 經過爲期三年的積極開發，新 2.6 Linux 內核最近已經發布了，在這期間，Linux 內核的開發和測試方法發生了一些有趣的變化。當前，開發內核的方法在很多方面與三年前沒什麼不同。不過，一些關鍵變化已經使整體的穩定性和質量得到了提高。 源代碼管理 歷史上，從來沒有出現過用於 Linux 內核的正式的源代碼管理或修正控制系統。實際上，很多開發者實現了他們自己的修正控制器，但是並沒有官方的 Linux CVS 檔案庫，讓 Linus Torvalds 檢查加入代碼，並讓其他人可以由此獲得代碼。修正控制器的缺乏，常常會使發行版本之間存在“代溝”，沒有人真正知道加入了哪些改變，這些改變是否能很好地融合，或者在即將發行的版本中哪些新內容是值得期待的。通常，如果更多的開發者可以像瞭解他們自己所做的改變一樣瞭解到那些變化，某些問題就可以得到避免。 由於缺乏正式的修正控制器和源代碼管理工具，使得很多人提議使用一個名爲 BitKeeper 的產品。BitKeeper 是一個源代碼控制管理系統，很多內核開發者已經成功地將其應用於他們自己的內核開發工作中。最初的 2.5 內核發佈後不久，Linus Torvalds 開始試用 BitKeeper，以確定它是否能滿足他的需要。現在，主要的 2.4 和 2.5 內核的 Linux 內核源代碼都是用 BitKeeper 來管理的。對大部分可能很少或者根本不關心內核開發的用戶來說，這一點看起來可能無關緊要。不過，在一些情況下，用戶可以受益於那些由於使用 BitKeeper 而帶來的開發 Linux 內核的方法的改變。 使用 BitKeeper 的最大好處之一是補丁的融合。當多個補丁應用於同一基礎的代碼之上，並且其中一些補丁會對同一部分產生影響時，就可能會出現融合問題。一個好的源代碼管理系統可以自動地完成其中一些更爲複雜的部分工作，這樣可以更快地融合補丁，並使更多的補丁加入到內核中。隨着 Linux 內核開發者社區的擴大，非常需要修正控制器來幫助保持對所有改變的追蹤。由於每個人都可以將這些改變集成到主要的 Linux 內核中，爲保證補丁不會被遺忘並可以方便地融合和管理，BitKeeper 等工具是必不可少的。 非常有必要使用一個實時的、集中的檔案庫來保存對 Linux 內核的最新更新。每一個被內核接受的改變或者補丁都被作爲一個改變集被追蹤。終端用戶和開發者可以保存他們自己的源文件檔案庫，並根據需要可以通過一個簡單的命令用最新的改變集進行更新。對開發者來說，這意味着可以始終使用最新的代碼拷貝。測試人員可以使用這些邏輯的改變集合來確定哪些變化導致了問題的產生，縮短調試所需要的時間。甚至那些希望使用最新內核的用戶也可以直接利用實時的、集中的檔案庫，因爲現在一旦他們所需要的部件或缺陷修復加入到內核中，他們就可以馬上進行更新。當代碼融合到內核時，任何用戶都可以提供關於這些代碼的即時反饋和缺陷報告。 並行開發 隨着 Linux 內核的成長，變得更加複雜，而且吸引更多開發者將注意力集中到內核的特定方面的專門開發上來，出現了另一個開發 Linux 方法的有趣改變。在 2.3 內核版本的開發期間，除了由 Linus Torvalds 發行的主要的一個內核樹之外，還有一些其他的內核樹。 在 2.5 的開發期間，內核樹出現了爆炸式的增長。由於使用源代碼管理工具可以保持開發的同步並行進行，這樣就可能實現開發的部分並行化。爲了讓其他人在他們所做的改變被接受之前可以進行測試，有一些開發需要並行化。那些保持自己的樹的內核維護者致力於特定的組件和目標，比如內存管理、NUMA 部件、改進擴展性和用於特定體系結構的代碼，還有一些樹收集並追蹤對許多小缺陷的糾正。  圖 1. Linux 2.5 開發樹 這種並行開發模型的優點是，它使得需要進行重大改變的開發者，或者針對一個特定的目標進行大量類似改變的那些開發者可以自由地在一個受控環境中開發，而並不影響其他人所用內核的穩定性。當開發者完成工作後，他們可以發佈針對 Linux 內核當前版本的補丁，以實現到此爲止他們所完成的改變。這樣，社區中的測試人員就可以方便地測試這些改變並提供反饋。當每一部分都被證明是穩定的之後，那些部分可以單獨地，或者甚至同時全部地，融合到主要 Linux 內核中。 在實際應用中測試 過去，Linux 內核測試方法圍繞開放源代碼開發模型進行。由於代碼一經發布後就公開給其他開發者進行審查，因此從來沒有出現過一個與其他形式的軟件開發類似的正式的驗證週期。這種方法背後的理論依據是“The Cathedral and the Bazaar”中所謂的“Linus 法則” ，這一法則的內容爲“衆人的眼光是雪亮的”。換句話說，高力度的審查可以找出大部分真正的大問題。 然而實際上，內核有很多複雜的相互聯繫。即使進行了足夠力度的審查，還是會漏過很多嚴重的缺陷。此外，最新的內核一經發布，終端用戶可以（也經常是） 下載並使用。2.4.0 發佈時，社區中很多人都提議進行更有組織的測試，以保證特定測試和代碼審查的強度。有組織的測試包括運用測試計劃、測試過程中的可重複性等等。使用所有的三種方法比最初只使用兩種方法會帶來更高的代碼質量。 Linux 測試項目 最早對 Linux 開始進行有組織測試的貢獻者是 Linux 測試項目 (Linux Test Project，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 法則應該有這樣一個結論，有一些缺陷比其他缺陷更容易被發現，因爲那些正是持續多日的內核迴歸測試所發現並處理的那些。在開發週期中和實際發佈之前能夠每天進行這些測試，這就使那些只關注完整發行版本的測試者可以將精力集中於更嚴重和耗時的缺陷。 可擴展測試平臺 另外一個名爲開放源代碼開發實驗室 (Open Source Development Labs, OSDL) 的團隊也爲 Linux 測試做出了重要的貢獻。2.4 內核發佈後不久，OSDL 創建了一個叫做可擴展測試平臺 (Scalable Test Platform，STP) 的系統。STP 是一個自動化的測試平臺，讓開發者和測試者可以運行 OSDL 硬件之上的系統所提供的測試。開發者甚至可以使用這個系統來測試他們自己的針對內核的補丁。可擴展測試平臺簡化了測試的步驟，因爲 STP 可以構建內核、設置測試、運行測試，並收集結果。然後得到結果以進行深入地比較。很多人無法接觸大型系統，比如具有 8 個處理器的 SMP 機器，而通過 STP，任何人都可以在像這樣的大型系統上運行測試，這個系統 (STP) 的另一個好處就在於此。 追蹤缺陷 自從 2.4 發佈以來，對 Linux 內核的有組織測試最大的改進之一是缺陷追蹤。過去，在 Linux 內核中發現的缺陷會報告給 Linux 內核郵件列表，報告給特定組件或者特定體系的郵件列表，或者直接報告給維護髮現缺陷的那部分代碼的個人。隨着開發和測試 Linux 的人數的增加，這個系統的不足之處很快就暴露了出來。在以前，除非人們對缺陷的報告可以驚人地維持下去，缺陷經常被遺漏、遺忘或者忽略。 現在，OSDL 安裝了一個缺陷追蹤系統，來報告和追蹤 Linux 內核的缺陷。系統經過了配置，這樣當某個組件的缺陷被報告時，那個組件的維護者就會得到通知。維護者既可以接受並修復那個缺陷，或重新指定缺陷 （如果最終確定實際上那是內核另外一部分的缺陷），也可以排除它（如果最終確定並不是真正的缺陷，比如錯誤配置的系統）。報告給郵件列表的缺陷還有丟失的危險，因爲越來越多的電子郵件湧向那個列表。然而，在缺陷追蹤系統中，始終有對每一個缺陷及其當前狀態的記錄。 大量信息 在爲將來的 2.6 Linux 內核進行開的過程中，除了這些自動化的信息管理方法之外，開放源代碼社區的不同成員還收集和追蹤了數量驚人的信息。 例如，在 Kernel Newbies 站點上創建了一個狀態列表，來保持對已經提出的內核新部件的追蹤。這個列表包含了以狀態排序的條目，如果它們已經完成了，則說明它們已經包含在哪個內核中，如果還沒有完成，則指出還需要多長時間。列表上很多條目的鏈接指向大型項目的 Web 站點，或者當條目較小時，鏈接指向一個解釋相應部件的電子郵件信息的拷貝。 同時，“post-halloween 文檔”告訴用戶即將到來的 2.6 內核有哪些可期待的東西。post-halloween 文檔的大部分討論內容是用戶需要注意的主要改變，以及需要更新的系統工具（爲了利用它們）。關心這一信息人的主要是那些期望提前瞭解 2.6 內核中有哪些內容的 Linux 發行商，還有終端用戶，這可以讓他們確定爲了能利用新部件是否有需要升級的程序。 Kernel Janitors 項目保持了（實際上現在還在保持）一個列表，內容是需要修復的較小缺陷和解決方法。這些缺陷解決方法中大部分是由於向內核打較大的補丁時需要改動很多部分代碼而導致的，比如有些地方會影響設備驅動程序。那些新近從事內核開發的人開始時的工作可以選擇列表中的條目，這樣讓他們可以通過小項目學習如何編寫內核代碼，同時有機會爲社區做出貢獻。 還有，在另一個預發佈的項目中，John Cherry 追蹤了在對每個已經發布的內核版本進行編譯時發現的錯誤和警告。這些編譯統計數字隨着時間的流逝一直持續下降，而且，以系統的形式來發布這些結果使得所取得的進展一目瞭然。在很多情況下，可以像使用 Kernel Janitors 列表一樣來利用這些警告和錯誤消息中的一部分，因爲編譯錯誤通常是由小的缺陷引起的，需要一些努力去修復。 最後，還有 Andrew Morton 的“must-fix”列表。由於他已經被選定爲 2.6 內核發佈後的維護者，他運用他的特權概括地列出了那些他認爲在最終的 2.6 內核發佈前最迫切需要解決方案的問題。must-fix 列表中包含了內核 Bugzilla 系統中的缺陷，需要完成的部件，以及其他已知的問題，這些問題如不解決將阻礙 2.6 發佈。這一信息可以幫助指明在新內核發佈前還需要哪些步驟；對那些關心這一萬衆期待的 2.6 內核發佈何時能完成的人來說，它還可以提供有價值的信息。 自從去年年底 2.6 內核發佈以後，這些資料中有一些已經明顯不再進行維護了。其他的相關工作在主要版本發佈後仍未結束，還要繼續進行後期的更新。有趣的是能看到哪些又被重新提起，有了哪些革新，我們又一次接近了一個主要發佈版本。 結束語 多數人在考慮內核的一個新的穩定版本時，第一個問題通常是“這一版本中有什麼新東西嗎？”實際上除了一些新特性和修復之外，在幕後還有一個隨着時間而不斷改進的過程。 在 Linux 社區中，開放源代碼開發日益興旺。致力於 Linux 內核和其他方面工作的編碼者之間聯繫是鬆散的，這就使得團隊可以成功地適應變化。在許多方面，相對於已經完成的很多單個的改進和缺陷修復而言，Linux 的開發和測試方法 —— 尤其是這些方法隨時間的推移得到了改進 —— 對新內核的可靠性影響更爲深遠。 關於作者 Paul Larson 爲 IBM Linux Technology Center 的 Linux Test 團隊工作。過去一年中，他從事的項目包括 Linux 測試項目、2.5/2.6 內核穩定性和內核代碼覆蓋分析。可以通過 [email protected] 與他聯繫。 (責任編輯：代君利) |