讓您的程式碼回歸 Linux 上游源頭進行更新：入門篇

© 2011，著作權所有。作者：Armijn Hemel & Ralf Baechle；譯者：林誠夏，自由軟體鑄造場。

此中譯版之授權條款為：創用CC - 姓名標示 3.0 台灣。

這份文件描述的內容是，晶片製造商需要採取哪些步驟，讓他們的程式碼成功地回歸 Linux 核心的上游開發主幹 (mainline) 進行更新。

為什麼要讓程式碼回歸上游源頭進行更新？

讓程式碼回歸上游源頭進行更新可以帶來各種不同的好處：最重要的是，您所修改的程式碼可以被更多人看到。將您所修改的程式碼儲放在某些 FTP 上讓人下載，其能見度必然會低於置放於 Linux 核心的開發主幹上。而如果程式碼是放置於 Linux 的核心主幹，這會更有助於其他人取得這些程式碼並下載利用，並使您所生產的晶片組或是主機板更具使用上的吸引性。此外，這也將會便利他人改良您的程式碼，並有助於該程式碼能一直保持在最新的更新狀態（Linux 核心的程式碼會經常地被更新修改）。

將您的程式碼回歸到上游源頭進行更新，並不代表其他程式開發者，會從程式碼上傳的第一天開始，就為您撰寫改良這些程式碼。至少在上傳這些程式碼的初期時，在程式開發上面投注最多時間成本的人將還是您本身。而儘管短期來說，您可能還需要花費一些額外的工程資源在程式的開發上，但是從中長期來看，讓程式碼回歸到 Linux 核心的上游主幹絕對會為您帶來值得的回報。

如何與 Linux 核心的上游開發者溝通

Linux 核心的社群開發者針對許多開發事項都已經有了成熟的運作規則，例如：程式碼的撰寫風格 (coding style)、開發者彼此間的連絡溝通方式等等。很多 Linux 核心的主要開發者都非常忙碌，因此在與這些人打交道時最好能遵循這些既定規則，以讓整個溝通流程可以儘可能地順暢進行。

適當調節您的個人期待

您第一次提交給 Linux 核心開發者的程式碼，有可能不會被接受，不被接受的原因可能基於不同的理由，例如：程式碼不符合既定的撰寫風格、程式碼的品質不如預期等等。不過請不要將這樣的回應視為您的程式碼被拒絕了，而是要將這些互動視為將您的程式碼成功匯入 Linux 核心主流的第一步。

有時候這些 Linux 核心開發者對您的回應可能非常簡要，或者看似急躁與不耐煩，同樣地，請不要將這樣的回應視為您的程式碼被拒絕了，這其實是您還需要多加些努力的信號。

準備與提交您的程式碼

將程式碼上傳回 Linux 核心主流的提交與準備工作文件，已經被整理在 Linux 核心源碼目錄下的這些位置：

• Documentation/CodingStyle
• Documentation/SubmitChecklist
• Documentation/SubmittingDrivers
• Documentation/SubmittingPatches

一般來說，程式碼的提交步驟要從程式碼的清整與格式調整開始，提交者要先將程式碼的格式調整到與 (CodingStyle) 目錄裡的指示文件相符。然後依據 "SubmitChecklist" 目錄裡的提交清單逐項檢查，餘下 "SubmittingDrivers" 與 "SubmittingPatches" 這兩個目錄的文件，則是存放實際提交步驟的說明文件。

當您根據目錄裡的撰寫標準調整完所欲提交的程式碼後，下一個步驟就是將這些程式碼分割為適當大小的修補程式 (patch) 以利提交。這是因為當修補程式的檔案過大時，會造成他人難以檢閱的結果，所以最好是將修補程式維持在合理的容量內。這樣處理的另一個好處在於，適當分割後的修補程式將可以獨立地被不同的 Linux 核心開發者檢閱，例如以下的範例事項，都適合分割為個別獨立的修補程式來進行提交：

• 修正程式特定的問題
• 修正特定的拼字錯誤
• 修正 Linux 核心裡許多地方都會發生的共同問題
• 新版的硬體驅動程式
• 增加對新式系統晶片 (SOC) 或是評估板的相關支援

修補程式的提交應以上述建議的方式進行，這樣才能確保這些修補程式被納進 Linux 核心時不會破壞了系統的運作，即便是暫時性系統失靈的狀況都得盡量的避免，因為這會使得故障排除的工作變得更為困難。Linux 核心是利用 "git-bisect" 這隻程式進行故障排除，而若是某個版本的 Linux 核心發生系統失靈的狀況，即使這僅是暫時性的失靈，都會讓 "git-bisect" 的運作變得非常困難，或者根本無法運作。

當您完成了程式碼的清整工作，依照 "CodingStyle" 目錄裡的文件進行格式調整，並依其性質適當地分割為獨立的修補程式之後，接下來便可以將這些修補程式發送出去了。如果這些修補程式是為了增加新作業系統或系統晶片的支援，所影響的層面會觸及到 Linux 核心數個不同領域，但這並不代表您需要將這些修補程式發送給 Linux 核心郵件列表上的每個人。舉例來說，ARM Linux 的維護成員們對於針對 MIPS 所撰寫的程式碼並不會太感興趣。若是您想要了解如何將程式碼發送給 Linux 核心適合的開發成員，Linux 核心源碼樹狀目錄下 "MAINTAINERS" 這個檔案，能協助您了解相關資訊。

舉例來說，"MAINTAINERS" 這個檔案裡您可以找到 squashfs 程式的相關資訊有：

M:      Phillip Lougher 
L:      
  這個 E-mail 地址已經被防止灌水惡意程式保護，您需要啟用 Java Script 才能觀看
  (subscribers-only)
W:      https://squashfs.org.uk
S:      Maintained
F:      Documentation/filesystems/squashfs.txt
F:      fs/squashfs/

"L" 指向針對 squashfs 這個特定子系統建立的郵件列表，"M" 代表 squashfs 主要維護成員的個人連絡信箱或是群組成員的共同連絡信箱。有時您會找不到個別專案的郵件列表或是專案成員連絡信箱的資訊，而若二種資訊都找不到的話，建議您再直接利用 這個 E-mail 地址已經被防止灌水惡意程式保護，您需要啟用 Java Script 才能觀看 這個信箱來發送您所欲提交的修補程式。

如果您遵循上述這幾個簡單規則，那麼讓您的程式碼回歸 Linux 核心上游進行更新應該就不會是一件難事。最後、我們想要提供您一個重要的建議：如果您對於向 Linux 核心上流提交程式碼這件事有任何的疑問，儘管向這些 Linux 核心的開發者提出您的疑問。一般來說，這些 Linux 核心的開發成員，將會非常樂意地回答您所提出的相關問題。

原文（英文版）檔案下載：ODT / PDF。