登入  |  English
開發者注意事項 讓您的程式碼回歸 Linux 上游源頭進行更新:入門篇

法律源地

本網站法律源地提供相當多自由軟體授權與法律的資訊,歡迎您閱讀這些資訊。

 

讓您的程式碼回歸 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





分類: 開發者注意事項