歡迎光臨
每天分享高質量文章

linux 內核開髮指南 – 7 高級主題

7. 高級主題

現在,希望您能夠掌握開發流程的工作方式。然而,還有更多的東西要學!本節將介紹 一些主題,這些主題對希望成為Linux內核開發過程常規部分的開發人員有幫助。

7.1. 使用Git管理補丁

內核使用分佈式版本控制始於2002年初,當時Linus首次開始使用專有的Bitkeeper應用 程式。雖然bitkeeper存在爭議,但它所體現的軟體版本管理方法卻肯定不是。分佈式 版本控制可以立即加速內核開發專案。在當前的時代,有幾種免費的比特保持器替代品。無論好壞,內核專案都將Git作為其選擇的工具。

使用Git管理補丁可以使開發人員的生活更加輕鬆,尤其是隨著補丁數量的增加。Git 也有其粗糙的邊緣和一定的危險,它是一個年輕和強大的工具,仍然在其開發人員完善 中。本文件不會試圖教會讀者如何使用git;這會是個巨長的文件。相反,這裡的重點 將是Git如何特別適合內核開發過程。想要加快Git的開發人員可以在以下網站上找到 更多信息:

http://git-scm.com/

http://www.kernel.org/pub/software/scm/git/docs/user-manual.html

在嘗試使用它使補丁可供其他人使用之前,第一要務是閱讀上述站點,對Git的工作 方式有一個扎實的瞭解。使用Git的開發人員應該能夠獲得主線儲存庫的副本,探索 修訂歷史,提交對樹的更改,使用分支等。瞭解Git用於重寫歷史的工具(如Rebase) 也很有用。Git有自己的術語和概念;Git的新用戶應該瞭解refs、遠程分支、索引、 快進合併、推拉、分離頭等。一開始可能有點嚇人,但這些概念不難通過一點學習來 理解。

使用git生成通過電子郵件提交的補丁是提高速度的一個很好的練習。

當您準備好開始安裝Git樹供其他人查看時,您當然需要一個可以從中提取的服務器。如果您有一個可以訪問Internet的系統,那麼使用git守護行程設置這樣的服務器相 對簡單。否則,免費的公共托管網站(例如github)開始出現在網絡上。成熟的開發 人員可以在kernel.org上獲得一個帳戶,但這些帳戶並不容易找到;有關更多信息, 請參閱 http://kernel.org/faq/

正常的Git工作流程涉及到許多分支的使用。每一條開發線都可以分為單獨的“主題 分支”,並獨立維護。Git的分支機構很便宜,沒有理由不免費使用它們。而且,在 任何情況下,您都不應該在任何您打算讓其他人從中受益的分支中進行開發。應該 小心地創建公開可用的分支;當它們處於完整的形式並準備好運行時(而不是之前), 合併開發分支的補丁。

Git提供了一些強大的工具,可以讓您重寫開發歷史。一個不方便的補丁(比如說, 一個打破二分法的補丁,或者有其他一些明顯的缺陷)可以在適當的位置修複,或者 完全從歷史中消失。一個補丁系列可以被重寫,就好像它是在今天的主線之上寫的 一樣,即使你已經花了幾個月的時間在寫它。可以透明地將更改從一個分支轉移到另 一個分支。等等。明智地使用git修改歷史的能力可以幫助創建問題更少的乾凈補丁集。

然而,過度使用這種能力可能會導致其他問題,而不僅僅是對創建完美專案歷史的 簡單痴迷。重寫歷史將重寫該歷史中包含的更改,將經過測試(希望)的內核樹變 為未經測試的內核樹。但是,除此之外,如果開發人員沒有對專案歷史的共享視圖, 他們就無法輕鬆地協作;如果您重寫了其他開發人員拉入他們儲存庫的歷史,您將 使這些開發人員的生活更加困難。因此,這裡有一個簡單的經驗法則:被匯出到其他 人的歷史在此後通常被認為是不可變的。

因此,一旦將一組更改推送到公開可用的服務器上,就不應該重寫這些更改。如果您 嘗試強制進行不會導致快進合併(即不共享同一歷史記錄的更改)的更改,Git將嘗 試強制執行此規則。可以重寫此檢查,有時可能需要重寫匯出的樹。在樹之間移動變 更集以避免Linux-next中的衝突就是一個例子。但這種行為應該是罕見的。這就是為 什麼開發應該在私有分支中進行(必要時可以重寫)並且只有在公共分支處於合理的 高級狀態時才轉移到公共分支中的原因之一。

當主線(或其他一組變更所基於的樹)前進時,很容易與該樹合併以保持領先地位。對於一個私有的分支,rebasing 可能是一個很容易跟上另一棵樹的方法,但是一旦 一棵樹被匯出到全世界,rebasing就不是一個選項。一旦發生這種情況,就必須進行 完全合併(merge)。合併有時是很有意義的,但是過於頻繁的合併會不必要地擾亂 歷史。在這種情況下,建議的技術是不經常合併,通常只在特定的發佈點(如主線-rc 發佈)合併。如果您對特定的更改感到緊張,則可以始終在私有分支中執行測試合併。在這種情況下,git rerere 工具很有用;它記住合併衝突是如何解決的,這樣您就 不必重覆相同的工作。

關於Git這樣的工具的一個最大的反覆抱怨是:補丁從一個儲存庫到另一個儲存庫的 大量移動使得很容易陷入錯誤建議的變更中,這些變更避開審查雷達進入主線。當內 核開發人員看到這種情況發生時,他們往往會感到不高興;在Git樹上放置未查看或 主題外的補丁可能會影響您將來獲取樹的能力。取用Linus:

你可以給我發補丁,但要我從你哪裡取一個Git補丁,我需要知道你知道
你在做什麼,我需要能夠相信事情而不去檢查每個個人改變。

(http://lwn.net/articles/224135/)。

為了避免這種情況,請確保給定分支中的所有補丁都與相關主題緊密相關;“驅動程式 修複”分支不應更改核心記憶體管理代碼。而且,最重要的是,不要使用Git樹來繞過 審查過程。不時的將樹的摘要發佈到相關的串列中,當時間合適時,請求 Linux-next 中包含該樹。

如果其他人開始發送補丁以包含到您的樹中,不要忘記查看它們。還要確保您維護正確 的作者信息; git am 工具在這方面做得最好,但是如果它通過第三方轉發給您, 您可能需要在補丁中添加“From:”行。

請求pull操作時,請務必提供所有相關信息:樹的位置、要拉的分支以及拉操作將導致 的更改。在這方面,git request pull 命令非常有用;它將按照其他開發人員的預期 格式化請求,並檢查以確保您記住了將這些更改推送到公共服務器。

7.2. 審查補丁

一些讀者當然會反對將本節與“高級主題”放在一起,因為即使是剛開始的內核開發人員 也應該檢查補丁。當然,學習如何在內核環境中編程沒有比查看其他人發佈的代碼更好 的方法了。此外,審閱者永遠供不應求;通過查看代碼,您可以對整個流程做出重大貢獻。

審查代碼可能是一個令人生畏的前景,特別是對於一個新的內核開發人員來說,他們 可能會對公開詢問代碼感到緊張,而這些代碼是由那些有更多經驗的人發佈的。不過, 即使是最有經驗的開發人員編寫的代碼也可以得到改進。也許對評審員(所有評審員) 最好的建議是:把評審評論當成問題而不是批評。詢問“在這條路徑中如何釋放鎖?” 總是比說“這裡的鎖是錯誤的”更好。

不同的開發人員將從不同的角度審查代碼。一些主要關註的是編碼樣式以及代碼行是 否有尾隨空格。其他人將主要關註補丁作為一個整體實現的變更是否對內核有好處。然而,其他人會檢查是否存在鎖定問題、堆棧使用過度、可能的安全問題、在其他 地方發現的代碼重覆、足夠的文件、對性能的不利影響、用戶空間ABI更改等。所有 型別的檢查,如果它們導致更好的代碼進入內核,都是受歡迎和值得的

赞(0)

分享創造快樂