Chinese (Traditional)

Warning

此文件的目的是爲讓中文讀者更容易閱讀和理解，而不是作爲一個分支。因此， 如果您對此文件有任何意見或改動，請先嘗試更新原始英文文件。如果要更改或 修正某處翻譯文件，請將意見或補丁發送給維護者（聯繫方式見下）。

Note

如果您發現本文檔與原始文件有任何不同或者有翻譯問題，請聯繫該文件的譯者， 或者發送電子郵件給胡皓文以獲取幫助：<2023002089@link.tyut.edu.cn>。

Original:

Documentation/process/1.Intro.rst

Translator:

時奎亮 Alex Shi <alex.shi@linux.alibaba.com>

校譯:

吳想成 Wu XiangCheng <bobwxc@email.cn> 胡皓文 Hu Haowen <2023002089@link.tyut.edu.cn> 葉宸佑 Chen-Yu Yeh <chenyou910331@gmail.com>

1. 引言

1.1. 內容提要

本節的其餘部分涵蓋了核心開發的過程，以及開發人員及其僱主在這方面可能遇到的 各種問題。有很多原因使核心程式碼應被合併到正式的（“主線”）核心中，包括對使用者 的自動可用性、多種形式的社群支援以及影響核心開發方向的能力。提供給Linux核心 的程式碼必須在與GPL相容的許可證下可用。

開發流程如何進行 介紹了開發過程、核心發布週期和合併視窗的機制。 涵蓋了補丁開發、審查和合併週期中的各個階段。還有一些關於工具和郵件列表的討論。 鼓勵希望開始核心開發的開發人員追蹤並修復缺陷以作為初步練習。

早期規劃 包括專案的早期規劃，重點是儘快讓開發社群 參與進來。

使代碼正確 是關於程式設計過程的；介紹了其他開發人員遇到的幾個 陷阱。也涵蓋了對補丁的一些要求，並且介紹了一些工具，這些工具有助於確保核心 補丁是正確的。

發布補丁 描述發布補丁以供評審的過程。為了讓開發社群能 認真對待，補丁必須被正確格式化和描述，並且必須發送到正確的地方。遵循本節中的 建議有助於確保您的工作能被較好地接納。

跟進 介紹了發布補丁之後發生的事情；工作在這時 還遠遠沒有完成。與審閱者一起工作是開發過程中的一個重要部分；本節提供了一些 關於如何在這個重要階段避免問題的提示。當補丁被合併到主線中時，開發人員要注意 不要假定任務已經完成。

進階主題 介紹了兩個“進階”主題：使用Git管理補丁 和查看其他人發布的補丁。

更多資訊 總結了有關核心開發的更多資訊，附帶有相關資源 連結。

1.2. 這個文件是關於什麼的

Linux核心有超過800萬行程式碼，每個版本的貢獻者超過1000人，是現存最大、最活躍的 自由軟體專案之一。從1991年開始，這個核心已經發展成為一個最好的作業系統元件， 執行在袖珍數位音樂播放器、桌上型電腦、現存最大的超級電腦以及所有類型的系統上。 它是一種適用於幾乎任何情況的強健、高效和可擴展的解決方案。

隨著Linux的發展，希望參與其開發的開發人員（和公司）的數量也在增加。硬體供應商 希望確保Linux能夠很好地支援他們的產品，使這些產品對Linux使用者具有吸引力。嵌入 式系統供應商使用Linux作為整合產品的元件，希望Linux能夠儘可能地勝任手頭的任務。 分銷商和其他基於Linux的軟體供應商切實關心Linux核心的功能、效能和可靠性。最終 使用者也常常希望修改Linux，使之能更好地滿足他們的需求。

Linux最引人注目的特性之一是這些開發人員可以存取它；任何具備必要技能的人都 可以改進Linux並影響其開發方向。專有產品不能提供這種開放性，這是自由軟體的 一個特點。如果有什麼不同的話，那就是核心比大多數其他自由軟體專案更開放。一 個典型的三個月核心開發週期可以涉及1000多個開發人員，他們為100多個不同的公 司（或者根本不隸屬公司）工作。

與核心開發社群合作並不是特別困難。但儘管如此，仍有許多潛在的貢獻者在嘗試做 核心工作時遇到了困難。核心社群已經發展出自己獨特的操作方式，使其能夠在每天 都要更改數千行程式碼的環境中順利執行（並產生高品質的產品）。因此，Linux核 心開發過程與專有的開發模式有很大的不同也就不足為奇了。

對於新開發人員來說，核心的開發過程可能會讓人感到奇怪和恐懼，但這背後有充分的 理由和堅實的經驗。一個不瞭解核心社群工作方式的開發人員（或者更糟的是，他們 試圖拋棄或規避之）會得到令人沮喪的體驗。開發社群在幫助那些試圖學習的人的同時， 沒有時間幫助那些不願意傾聽或不關心開發過程的人。

希望閱讀本文的人能夠避免這種令人沮喪的經歷。這些材料很長，但閱讀它們時所做的 努力會在短時間內得到回報。開發社群總是需要能讓核心變更好的開發人員；下面的 文字應該幫助您或為您工作的人員加入我們的社群。

1.3. 致謝

本文件由Jonathan Corbet <corbet@lwn.net> 撰寫。以下人員的建議使之更為完善： Johannes Berg, James Berry, Alex Chiang, Roland Dreier, Randy Dunlap, Jake Edge, Jiri Kosina, Matt Mackall, Arthur Marsh, Amanda McPherson, Andrew Morton, Andrew Price, Tsugikazu Shibata 和 Jochen Voß 。

這項工作得到了Linux基金會的支援，特別感謝Amanda McPherson，他看到了這項工作 的價值並將其變成現實。

1.4. 程式碼進入主線的重要性

有些公司和開發人員偶爾會想，為什麼他們要費心學習如何與核心社群合作，並將程 式碼放入主線核心（“主線”是由Linus Torvalds維護的核心，Linux發行商將其用作 基礎）。在短期內，貢獻程式碼看起來像是一種可以避免的開銷；維護獨立程式碼並 直接支援使用者似乎更容易。事實上，保持程式碼獨立（“樹外”）是在經濟上是錯誤 的。

為了說明樹外程式碼成本，下面給出核心開發過程的一些相關方面；本文稍後將更詳細地 討論其中的大部分內容。請考慮：

  • 所有Linux使用者都可以使用合併到主線核心中的程式碼。它將自動出現在所有啟 用它的發行版上。無需驅動程式磁碟、額外下載，也不需要為多個發行版的多個版 本提供支援；這一切將方便所有開發人員和使用者。併入主線解決了大量的分發和 支援問題。

  • 當核心開發人員努力維護一個穩定的使用者空間介面時，核心內部API處於不斷變 化之中。不維持穩定的內部介面是一個慎重的設計決策；它允許在任何時候進行基 本的改進，並產出更高品質的程式碼。但該策略導致結果是，若要使用新的核心， 任何樹外程式碼都需要持續的維護。維護樹外程式碼會需要大量的工作才能使程式 碼保持正常執行。

    相反，位於主線中的程式碼不需要這樣做，因為基本規則要求進行API更改的任何開發 人員也必須修復由於該更改而破壞的任何程式碼。因此，合併到主線中的程式碼大大降低 了維護成本。

  • 除此之外，核心中的程式碼通常會被其他開發人員改進。您授權的使用者社群和客 戶對您產品的改進可能會令人驚喜。

  • 核心程式碼在合併到主線之前和之後都要經過審查。無論原始開發人員的技能有多 強，這個審查過程總是能找到改進程式碼的方法。審查經常發現嚴重的錯誤和安全 問題。對於在封閉環境中開發的程式碼尤其如此；這種程式碼從外部開發人員的審 查中獲益匪淺。樹外程式碼是低品質程式碼。

  • 參與開發過程是您影響核心開發方向的方式。旁觀者的抱怨會被聽到，但是活躍的 開發人員有更強的聲音——並且能夠實作使核心更好地滿足其需求的更改。

  • 當單獨維護程式碼時，總是存在第三方為類似功能提供不同實作的可能性。如果發 生這種情況，合併程式碼將變得更加困難——甚至成為不可能。之後，您將面臨以下 令人不快的選擇：（1）無限期地維護樹外的非標準特性，或（2）放棄程式碼並將 使用者遷移到樹內版本。

  • 程式碼的貢獻是使整個流程工作的根本。透過貢獻程式碼，您可以向核心添加新功 能，並提供其他核心開發人員使用的功能和範例。如果您已經為Linux開發了程式 碼（或者正在考慮這樣做），那麼您顯然對這個平臺的持續成功感興趣；貢獻程式 碼是確保成功的最好方法之一。

上述所有理由都適用於任何樹外核心程式碼，包括以專有的、僅二進位形式分發的程 式碼。然而，在考慮任何類型的純二進位核心程式碼分發之前，還需要考慮其他因素。 包括：

  • 圍繞專有核心模組分發的法律問題其實較為模糊；相當多的核心版權所有者認為， 大多數僅二進位的模組是核心的派生產品，因此，它們的分發違反了GNU通用公共 許可證（下面將詳細介紹）。本文作者不是律師，本文件中的任何內容都不可能被 視為法律建議。封閉原始程式碼模組的真實法律地位只能由法院決定。但不管怎樣， 困擾這些模組的不確定性仍然存在。

  • 二進位模組大大增加了除錯核心問題的難度，以至於大多數核心開發人員甚至都不會 嘗試。因此，只分發二進位模組將使您的使用者更難從社群獲得支援。

  • 對於僅二進位的模組的發行者來說，支援也更加困難，他們必須為他們希望支援的 每個發行版和每個核心版本提供不同版本的模組。為了提供較為全面的覆蓋範圍， 可能需要一個模組的幾十個建置，並且每次升級核心時，您的使用者都必須單獨升級 這些模組。

  • 上面提到的關於程式碼評審的所有問題都更加存在於封閉原始程式碼中。由於該程 式碼根本不可得，因此社群無法對其進行審查，毫無疑問，它將存在嚴重問題。

尤其是嵌入式系統的製造商，可能會傾向於忽視本節中所說的大部分內容；因為他們 相信自己正在商用一種使用凍結核心版本的獨立產品，在發布後不需要再進行開發。 這個論點忽略了廣泛的程式碼審查的價值以及允許使用者向產品添加功能的價值。但這些 產品的商業壽命有限，之後必須發布新版本的產品。在這一點上，程式碼在主線上並得到 良好維護的供應商將能夠更好地佔位，以使新產品快速上市。

1.5. 許可

程式碼是根據一些許可證提供給Linux核心的，但是所有程式碼都必須與GNU通用公共許可 證（GPLv2）的版本2相容，該版本是覆蓋整個核心分發的許可證。在實踐中，這意味 著所有程式碼貢獻都由GPLv2（可選地，語言允許在更高版本的GPL下分發）或3子句BSD 許可（New BSD License，譯者注）覆蓋。任何不包含在相容許可證中的貢獻都不會 被接受到核心中。

貢獻給核心的程式碼不需要（或請求）版權分配。合併到主線核心中的所有程式碼都保留 其原始所有權；因此，核心現在擁有數千個所有者。

這種所有權結構也暗示著，任何改變核心許可的嘗試都註定會失敗。很少有實際情況 可以獲得所有版權所有者的同意（或者從核心中刪除他們的程式碼）。因此，尤其是在 可預見的將來，許可證不大可能遷移到GPL的版本3。

所有貢獻給核心的程式碼都必須是合法的自由軟體。因此，不接受身分不明或匿名的 貢獻者的程式碼。所有貢獻者都需要在他們的程式碼上“sign off（簽發）”，聲明程 式碼可以在GPL下與核心一起分發。無法提供未被其所有者許可為自由軟體的程式碼， 或可能為核心造成版權相關問題的程式碼（例如，由缺乏適當保護的反向工程工作派 生的程式碼）不能被接受。

有關版權問題的提問在Linux開發郵件列表中很常見。這樣的問題通常會得到不少答 案，但請記住，回答這些問題的人不是律師，不能提供法律諮詢。如果您有關於 Linux原始程式碼的法律問題，沒有什麼可以代替諮詢瞭解這一領域的律師。依賴從 技術郵件列表中獲得的答案是一件冒險的事情。