原文

這是關(guān)于這個(gè)話題的全部，最終的文件。 它包含有關(guān)如何成為L(zhǎng)inux內(nèi)核開發(fā)人員以及如何學(xué)習(xí)如何與Linux內(nèi)核開發(fā)社區(qū)合作的說明。 它試圖不包含與內(nèi)核編程的技術(shù)方面有關(guān)的任何東西，但會(huì)幫助你指出正確的方向。

如果本文檔中的任何內(nèi)容過期，請(qǐng)將補(bǔ)丁發(fā)送給本文檔底部列出的此文件的維護(hù)人員。

介紹

那么，你想學(xué)習(xí)如何成為L(zhǎng)inux內(nèi)核開發(fā)者？ 或者您的經(jīng)理已經(jīng)告訴您“為此設(shè)備編寫一個(gè)Linux驅(qū)動(dòng)程序”。本文檔的目標(biāo)是通過描述您需要經(jīng)過的過程向您介紹所需的一切信息，并提示如何實(shí)現(xiàn)這一目標(biāo) 與社區(qū)合作。 它也將試圖解釋社區(qū)為什么像這樣工作的一些原因。

內(nèi)核主要用C語言編寫，其中一些與構(gòu)件相關(guān)的部分用匯編語言編寫。 內(nèi)核開發(fā)需要對(duì)C有一個(gè)很好的理解。 程序集（任何體系結(jié)構(gòu)）不是必需的，除非你打算為該體系結(jié)構(gòu)進(jìn)行低級(jí)開發(fā)。 雖然他們不是一個(gè)堅(jiān)實(shí)的C教育和/或多年的經(jīng)驗(yàn)的好替代品，但下面的書是好的，如果有的話，可以參考：

• “The C Programming Language” by Kernighan and Ritchie [Prentice Hall]
• “Practical C Programming” by Steve Oualline [O’Reilly]
• “C: A Reference Manual” by Harbison and Steele [Prentice Hall]

內(nèi)核是使用GNU C和GNU工具鏈編寫的。 雖然它符合ISO C89標(biāo)準(zhǔn)，但它使用了許多標(biāo)準(zhǔn)中沒有的擴(kuò)展功能。 內(nèi)核是一個(gè)獨(dú)立的C環(huán)境，不依賴于標(biāo)準(zhǔn)C庫，因此C標(biāo)準(zhǔn)的某些部分不被支持。 任意長(zhǎng)分歧和浮點(diǎn)是不允許的。 有時(shí)難以理解內(nèi)核對(duì)工具鏈和它所使用的擴(kuò)展的假設(shè)，不幸的是沒有明確的參考。 請(qǐng)檢查gcc info pages（info gcc）的一些信息。

請(qǐng)記住，您正試圖學(xué)習(xí)如何與現(xiàn)有的開發(fā)社區(qū)合作。 它是一個(gè)多元化的人群，具有高標(biāo)準(zhǔn)的編碼，風(fēng)格和程序。 隨著時(shí)間的推移，這些標(biāo)準(zhǔn)已經(jīng)被創(chuàng)造出來，基于他們發(fā)現(xiàn)對(duì)于這樣一個(gè)地理上分散的大型團(tuán)隊(duì)來說最好的工作。 盡可能提前了解這些標(biāo)準(zhǔn)，因?yàn)檫@些標(biāo)準(zhǔn)是有據(jù)可查的; 不要指望人們適應(yīng)你或你公司的做事方式。

法律問題

Linux內(nèi)核源代碼是在GPL下發(fā)布的。 有關(guān)許可證的詳細(xì)信息，請(qǐng)參閱源代碼樹主目錄中的COPYING文件。 如果您有關(guān)于許可證的進(jìn)一步問題，請(qǐng)聯(lián)系律師，而不要在Linux內(nèi)核郵件列表上詢問。 郵件列表上的人不是律師，你不應(yīng)該依賴他們?cè)诜墒聞?wù)上的陳述。

有關(guān)GPL的常見問題和答案，請(qǐng)參閱：
https://www.gnu.org/licenses/gpl-faq.html

文檔

Linux內(nèi)核源代碼樹有大量的文檔，對(duì)于學(xué)習(xí)如何與內(nèi)核社區(qū)交互是非常有價(jià)值的。 將新功能添加到內(nèi)核時(shí)，建議添加新的文檔文件，以解釋如何使用該功能。 當(dāng)內(nèi)核更改導(dǎo)致內(nèi)核暴露給用戶空間的界面發(fā)生變化時(shí)，建議您在mtk.manpages@gmail.com和CC 列表linux-api@vger.kernel.org將手動(dòng)頁面的信息或補(bǔ)丁發(fā)送給手冊(cè)頁面維護(hù)人員。

以下是內(nèi)核源代碼樹中需要讀取的文件列表：

• README
  該文件給出了Linux內(nèi)核的簡(jiǎn)短背景，并描述了配置和構(gòu)建內(nèi)核的必要步驟。 內(nèi)核新手應(yīng)該從這里開始。
• Documentation/process/changes.rst
  該文件給出了構(gòu)建和運(yùn)行內(nèi)核所需的各種軟件包的最低級(jí)別列表。
• Documentation/process/coding-style.rst
  這描述了Linux內(nèi)核的編碼風(fēng)格，以及它背后的一些基本原理。 預(yù)計(jì)所有新代碼將遵循本文檔中的指導(dǎo)原則。 如果遵循這些規(guī)則，大多數(shù)維護(hù)人員只會(huì)接受補(bǔ)丁程序，而且許多人只有在正確的風(fēng)格下才會(huì)審查代碼。
• Documentation/process/submitting-patches.rstandDocumentation/process/submitting-drivers.rst
  這些文件詳細(xì)描述了如何成功創(chuàng)建和發(fā)送補(bǔ)丁，包括（但不限于）：
  • 電子郵件內(nèi)容
  • 電子郵件格式
  • 發(fā)送給誰
    遵循這些規(guī)則并不能保證成功（因?yàn)樗械难a(bǔ)丁都受到內(nèi)容和風(fēng)格的審查），但不遵循這些規(guī)則幾乎總是不會(huì)通過。

關(guān)于如何正確創(chuàng)建補(bǔ)丁的其他優(yōu)秀描述如下：
“完美的補(bǔ)丁”：
https://www.ozlabs.org/~akpm/stuff/tpp.txt
“Linux內(nèi)核補(bǔ)丁提交格式”：
http://linux.yyz.us/patch-format.html

• Documentation/process/stable-api-nonsense.rst
  這個(gè)文件描述了有意識(shí)決定在內(nèi)核中沒有一個(gè)穩(wěn)定的API的基本原理，包括如下內(nèi)容：
  • 子系統(tǒng)墊片層（兼容性？）
  • 操作系統(tǒng)之間的驅(qū)動(dòng)程序可移植
  • 減輕內(nèi)核源代碼樹中的快速變化（或防止快速變化）

本文檔對(duì)于理解Linux開發(fā)理念至關(guān)重要，對(duì)于從其他操作系統(tǒng)開發(fā)人員轉(zhuǎn)向Linux的人員非常重要。

• Documentation/admin-guide/security-bugs.rst
  如果您覺得在Linux內(nèi)核中發(fā)現(xiàn)安全問題，請(qǐng)按照本文檔中的步驟來幫助通知內(nèi)核開發(fā)人員，并幫助解決問題。
• Documentation/process/management-style.rst
  本文檔描述了Linux內(nèi)核維護(hù)者如何操作以及他們方法背后的共同特征。 對(duì)于任何一個(gè)新的內(nèi)核開發(fā)人員（或者只是對(duì)此感到好奇的人）來說，這是一個(gè)重要的閱讀，因?yàn)樗鉀Q了很多關(guān)于內(nèi)核維護(hù)人員獨(dú)特行為的常見誤解和困惑。
• Documentation/process/stable-kernel-rules.rst
  這個(gè)文件描述了穩(wěn)定的內(nèi)核釋放如何發(fā)生的規(guī)則，以及如果你想要改變到這些版本之一該怎么做。
• Documentation/process/kernel-docs.rst
  與內(nèi)核開發(fā)相關(guān)的外部文檔列表。 如果在內(nèi)核文檔中找不到你要找的內(nèi)容，請(qǐng)查閱這個(gè)列表。
• Documentation/process/applying-patches.rst
  一個(gè)很好的介紹，描述了一個(gè)補(bǔ)丁是什么以及如何將它應(yīng)用到內(nèi)核的不同開發(fā)分支。

內(nèi)核也有大量的文件，可以從源代碼本身或ReStructuredText標(biāo)記（ReST）自動(dòng)生成，就像這樣。 這包括對(duì)內(nèi)核API的完整描述，以及如何正確處理鎖定的規(guī)則。

所有這些文件可以通過運(yùn)行生成PDF或HTML：

make pdfdocs
make htmldocs

分別來自主內(nèi)核源碼目錄。

使用ReST標(biāo)記的文檔將在文檔/輸出中生成。 它們也可以在LaTeX和ePub格式上生成：

make latexdocs
make epubdocs

目前，在DocBook上有一些正在轉(zhuǎn)換為ReST的文檔。 這些文檔將在Documentation/DocBook/目錄下創(chuàng)建，也可以通過運(yùn)行生成為Postscript或手冊(cè)頁：

Becoming A Kernel Developer

如果你對(duì)Linux內(nèi)核開發(fā)一無所知，你應(yīng)該看看Linux KernelNewbies項(xiàng)目：

https://kernelnewbies.org

它包含一個(gè)有用的郵件列表，你幾乎可以問任何類型的基本的內(nèi)核開發(fā)問題（在問一些以前已經(jīng)回答的問題之前，一定要首先搜索檔案）。它還有一個(gè)IRC頻道，你可以 用于實(shí)時(shí)提問，以及大量有用的文檔，這對(duì)于學(xué)習(xí)Linux內(nèi)核開發(fā)很有幫助。

該網(wǎng)站有關(guān)于代碼組織，子系統(tǒng)和當(dāng)前項(xiàng)目（樹中和樹外）的基本信息。 它還描述了一些基本的物流信息，比如如何編譯內(nèi)核和應(yīng)用補(bǔ)丁。

如果你不知道你想從哪里開始，但是你想尋找一些開始加入到內(nèi)核開發(fā)社區(qū)的任務(wù)，請(qǐng)轉(zhuǎn)到Linux Kernel Janitor的項(xiàng)目：

https://kernelnewbies.org/KernelJanitors

這是一個(gè)很好的開始。 它描述了一個(gè)相對(duì)簡(jiǎn)單的問題清單，需要在Linux內(nèi)核源碼樹中進(jìn)行清理和修復(fù)。 與負(fù)責(zé)這個(gè)項(xiàng)目的開發(fā)人員一起工作，您將學(xué)習(xí)如何將您的補(bǔ)丁納入Linux內(nèi)核樹的基礎(chǔ)知識(shí)，如果您還沒有任何想法，可能會(huì)指出接下來要做什么的方向。

如果你已經(jīng)有了一段你想要放到內(nèi)核樹中的代碼，但是需要一些幫助以正確的方式獲得它，那么就創(chuàng)建一個(gè)kernel-mentors項(xiàng)目來幫助你解決這個(gè)問題。 這是一個(gè)郵件列表，可以在以下網(wǎng)址找到：

https://selenic.com/mailman/listinfo/kernel-mentors

在對(duì)Linux內(nèi)核代碼做任何實(shí)際的修改之前，理解代碼是如何工作是非常重要的。 為此，沒有什么比直接閱讀（最棘手的部分評(píng)論得好），也許甚至在專門的工具的幫助下。 Linux交叉引用項(xiàng)目是一個(gè)特別推薦的工具，它能夠以自引用索引的網(wǎng)頁格式顯示源代碼。 一個(gè)優(yōu)秀的最新的內(nèi)核代碼庫可以在以下位置找到：

http://lxr.free-electrons.com/

開發(fā)過程

Linux內(nèi)核開發(fā)過程目前由幾個(gè)不同的主內(nèi)核“分支”和許多不同的子系統(tǒng)特定的內(nèi)核分支組成。 這些不同的分支是：

• main 4.x kernel tree
• 4.x.y -stable kernel tree
• 4.x -git kernel patches
• subsystem specific kernel trees and patches
• the 4.x -next kernel tree for integration tests

4.x kernel tree

4.x內(nèi)核由Linus Torvalds維護(hù)，可以在pub/linux/kernel/v4.x/目錄下的https://kernel.org上找到。其發(fā)展過程如下：

• 只要一個(gè)新的內(nèi)核被發(fā)布，兩個(gè)星期的窗口就會(huì)被打開，在這段時(shí)間里，維護(hù)者可以向Linus提交大的差異，通常是已經(jīng)包含在-next內(nèi)核中幾個(gè)星期的補(bǔ)丁。提交重大更改的首選方法是使用git（內(nèi)核的源代碼管理工具，更多信息可以在https://git-scm.com/找到），但是普通的補(bǔ)丁也很好。
• 兩個(gè)星期后，一個(gè)-rc1內(nèi)核被釋放，重點(diǎn)在于使得新內(nèi)核盡可能堅(jiān)如磐石。現(xiàn)在大部分補(bǔ)丁都應(yīng)該修復(fù)一個(gè)回歸。一直存在的錯(cuò)誤不是回歸，所以只有在重要的時(shí)候才推動(dòng)這些修復(fù)。請(qǐng)注意，在-rc1之后可能會(huì)接受一個(gè)全新的驅(qū)動(dòng)程序（或文件系統(tǒng)），因?yàn)橹灰氖亲园模⑶也粫?huì)影響代碼之外的區(qū)域添加。在發(fā)布-rc1之后，可以使用git將修補(bǔ)程序發(fā)送給Linus，但是修補(bǔ)程序也需要發(fā)送到公共郵件列表以供審查。
• 每當(dāng)Linus認(rèn)為當(dāng)前的git樹處于一個(gè)合理穩(wěn)定的狀態(tài)，足以進(jìn)行測(cè)試時(shí)，就會(huì)發(fā)布一個(gè)新的-rc。目標(biāo)是每周發(fā)布一個(gè)新的-rc內(nèi)核。
• 進(jìn)程一直持續(xù)到內(nèi)核被認(rèn)為是“準(zhǔn)備就緒”，這個(gè)過程應(yīng)該持續(xù)大約6個(gè)星期。

值得一提的是Andrew Morton在linux-kernel郵件列表中關(guān)于內(nèi)核版本的內(nèi)容：

“Nobody knows when a kernel will be released, because it’s released according to perceived bug status, not according to a preconceived timeline.”

4.x.y -stable kernel tree

具有3部分版本的內(nèi)核是穩(wěn)定的內(nèi)核。 它們包含相對(duì)較小和重要的安全問題修復(fù)或在給定的4.x內(nèi)核中發(fā)現(xiàn)的顯著回退。

對(duì)于那些想要最新的穩(wěn)定內(nèi)核并且對(duì)幫助測(cè)試開發(fā)/實(shí)驗(yàn)版本不感興趣的用戶，這是推薦的分支。

如果沒有可用的4.x.y內(nèi)核，則最高編號(hào)的4.x內(nèi)核是當(dāng)前穩(wěn)定的內(nèi)核。

4.x.y由“stable”團(tuán)隊(duì)stable@vger.kernel.org維護(hù)，并根據(jù)需要發(fā)布。 正常釋放時(shí)間大約為兩周，但如果沒有緊迫問題，則可能會(huì)更長(zhǎng)。 與安全相關(guān)的問題反而會(huì)導(dǎo)致發(fā)布幾乎立即發(fā)生。

內(nèi)核樹中的Documentation/process/stable-kernel-rules.rst文件記錄了-stable樹可以接受哪些類型的更改以及發(fā)布過程如何工作。

4.x -git patches

這些是Linus內(nèi)核樹的每日快照，這些快照是在git存儲(chǔ)庫（因此得名）中管理的。這些補(bǔ)丁通常每天發(fā)布，代表Linus樹的當(dāng)前狀態(tài)。 它們比-rc內(nèi)核更具實(shí)驗(yàn)性，因?yàn)樗鼈兪亲詣?dòng)生成的，不用粗略一眼就能看出它們是否理智。

Subsystem Specific kernel trees and patches

各種內(nèi)核子系統(tǒng)的維護(hù)者（以及許多內(nèi)核子系統(tǒng)開發(fā)者）在源代碼庫中公開了他們當(dāng)前的開發(fā)狀態(tài)。 這樣，其他人可以看到內(nèi)核的不同區(qū)域發(fā)生了什么。 在發(fā)展迅速的領(lǐng)域，可能會(huì)要求開發(fā)人員將其提交的內(nèi)容基于子系統(tǒng)內(nèi)核樹，以避免提交與其他已經(jīng)進(jìn)行的工作之間的沖突。

這些倉(cāng)庫中的大部分都是git樹，但也有其他SCM正在使用，或者補(bǔ)丁隊(duì)列被發(fā)布為quilt系列。 這些子系統(tǒng)存儲(chǔ)庫的地址列在MAINTAINERS文件中。 他們中的許多人可以瀏覽https://git.kernel.org/。

在提議的補(bǔ)丁程序被提交給這樣的子系統(tǒng)樹之前，需要審查哪些主要發(fā)生在郵件列表上（參見下面的相應(yīng)部分）。 對(duì)于幾個(gè)內(nèi)核子系統(tǒng)，這個(gè)評(píng)估過程是通過工具拼湊來跟蹤的。 Patchwork提供一個(gè)Web界面，顯示補(bǔ)丁發(fā)布，補(bǔ)丁上的任何評(píng)論或修改，維護(hù)人員可以將補(bǔ)丁標(biāo)記為審閱，接受或拒絕。 大多數(shù)這些拼湊網(wǎng)站都列在https://patchwork.kernel.org/。

4.x -next kernel tree for integration tests

在子系統(tǒng)樹更新合并到主線4.x樹之前，需要對(duì)其進(jìn)行集成測(cè)試。 為此，存在一個(gè)特殊的測(cè)試資源庫，幾乎所有的子系統(tǒng)樹都幾乎每天都被提取出來：

https://git.kernel.org/?p=linux/kernel/git/next/linux-next.git

這樣，下一個(gè)內(nèi)核就會(huì)給出一個(gè)總結(jié)性的展望，看看下一個(gè)合并期間將會(huì)進(jìn)入主線內(nèi)核的內(nèi)容。 冒險(xiǎn)的測(cè)試者非常歡迎運(yùn)行時(shí)測(cè)試-next內(nèi)核。

Bug Reporting

https://bugzilla.kernel.org是Linux內(nèi)核開發(fā)者跟蹤內(nèi)核錯(cuò)誤的地方。 鼓勵(lì)用戶報(bào)告他們?cè)谶@個(gè)工具中找到的所有錯(cuò)誤。 有關(guān)如何使用內(nèi)核bugzilla的詳細(xì)信息，請(qǐng)參閱：

https://bugzilla.kernel.org/page.cgi?id=faq.html

主內(nèi)核源代碼目錄下的文件admin-guide / reporting-bugs.rst為如何報(bào)告可能的內(nèi)核錯(cuò)誤提供了一個(gè)很好的模板，并且詳細(xì)說明了內(nèi)核開發(fā)者需要什么樣的信息來幫助跟蹤這個(gè)問題。

Managing bug reports

實(shí)施黑客技能的最佳方法之一是修復(fù)其他人報(bào)告的錯(cuò)誤。 不僅你會(huì)幫助內(nèi)核更穩(wěn)定，你將學(xué)習(xí)解決現(xiàn)實(shí)世界的問題，你會(huì)提高你的技能，其他開發(fā)人員會(huì)意識(shí)到你的存在。 修復(fù)錯(cuò)誤是在其他開發(fā)人員中獲得優(yōu)勢(shì)的最好方法之一，因?yàn)闆]有多少人浪費(fèi)時(shí)間來修復(fù)其他人的錯(cuò)誤。

要在已報(bào)告的錯(cuò)誤報(bào)告中工作，請(qǐng)轉(zhuǎn)到https://bugzilla.kernel.org。 如果您希望獲得有關(guān)未來錯(cuò)誤報(bào)告的建議，您可以訂閱bugme-new郵件列表（僅郵寄新錯(cuò)誤報(bào)告）或bugme-janitor郵件列表（bugzilla中的每個(gè)更改均會(huì)在此郵寄）

https://lists.linux-foundation.org/mailman/listinfo/bugme-new

https://lists.linux-foundation.org/mailman/listinfo/bugme-janitors

Mailing lists

正如上面的一些文檔所描述的那樣，大多數(shù)核心內(nèi)核開發(fā)者都參與了Linux內(nèi)核郵件列表。 有關(guān)如何訂閱和取消訂閱的詳細(xì)信息，請(qǐng)?jiān)L問：

http://vger.kernel.org/vger-lists.html#linux-kernel
在很多不同的地方都有網(wǎng)上郵件列表的存檔。 使用搜索引擎來查找這些檔案。 例如：

http://dir.gmane.org/gmane.linux.kernel
強(qiáng)烈建議您在將其發(fā)布到列表之前，搜索關(guān)于您想要調(diào)出的主題的檔案。 很多已經(jīng)詳細(xì)討論過的東西只能在郵件列表中記錄下來。

大多數(shù)單獨(dú)的內(nèi)核子系統(tǒng)也都有自己的獨(dú)立郵件列表，他們?cè)谶@里進(jìn)行開發(fā)工作。 請(qǐng)參閱MAINTAINERS文件以獲取這些列表針對(duì)不同組的列表。

許多列表都在kernel.org上。 有關(guān)它們的信息可在以下網(wǎng)址找到：

http://vger.kernel.org/vger-lists.html

請(qǐng)記住在使用列表時(shí)要遵循良好的行為習(xí)慣。 盡管有點(diǎn)俗氣，下面的URL有一些與列表（或任何列表）交互的簡(jiǎn)單指導(dǎo)：

http://www.albion.com/netiquette/

如果多人回復(fù)您的郵件，收件人列表可能會(huì)變得非常大。 不要從沒有任何理由的CC：列表中刪除任何人，也不要只回復(fù)列表地址。 習(xí)慣于接收郵件兩次，一次來自發(fā)件人和一份來自列表的郵件，不要試圖通過添加花哨的郵件頭來調(diào)整郵件，人們不會(huì)喜歡它。

請(qǐng)記住保持您的回復(fù)的上下文和歸屬，并在回復(fù)頂部保留“John Kernelhacker writing ...：”行，并在各個(gè)引用部分之間添加您的語句，而不是寫在郵件頂部。

如果您將修補(bǔ)程序添加到郵件中，請(qǐng)確保它們是可讀的文本，如Documentation/process/submitting-patches.rst中所述。 內(nèi)核開發(fā)人員不想處理附件或壓縮補(bǔ)丁; 他們可能想對(duì)你的補(bǔ)丁的個(gè)別行發(fā)表評(píng)論，這只能用于這種方式。 確保你使用的郵件程序不會(huì)破壞空格和制表符。 一個(gè)好的第一個(gè)測(cè)試就是把郵件發(fā)送給自己，并嘗試自己應(yīng)用自己的補(bǔ)丁。 如果這不起作用，請(qǐng)修復(fù)您的郵件程序或更改它，直到它工作。

最重要的是，請(qǐng)記住尊重其他用戶。

Working with the community

內(nèi)核社區(qū)的目標(biāo)是提供最好的內(nèi)核。 當(dāng)你提交一個(gè)可以接受的補(bǔ)丁的時(shí)候，將會(huì)對(duì)它的技術(shù)特性和那些單獨(dú)的補(bǔ)丁進(jìn)行評(píng)估。 那么，你應(yīng)該期待什么？

• 批評(píng)
• 注釋
• 要求改變
• 請(qǐng)求理由
• 安靜

請(qǐng)記住，這是將你的補(bǔ)丁加入內(nèi)核的一部分。 您必須能夠?qū)δ难a(bǔ)丁進(jìn)行批評(píng)和評(píng)論，在技術(shù)層面對(duì)其進(jìn)行評(píng)估，并重新修補(bǔ)您的補(bǔ)丁或提供清晰，簡(jiǎn)明的推理，說明為什么不應(yīng)該進(jìn)行修改。 如果您的帖子沒有回復(fù)，請(qǐng)等待幾天再試一次，有時(shí)甚至?xí)G失大量的信息。

你不應(yīng)該做什么？

• 希望您的補(bǔ)丁能夠毫無疑問地被接受
• 變得防守
• 忽略評(píng)論
• 重新提交修補(bǔ)程序而不進(jìn)行任何請(qǐng)求的更改

在一個(gè)正在尋求最佳技術(shù)解決方案的社區(qū)中，對(duì)于補(bǔ)丁的有效性總會(huì)有不同的看法。 你必須合作，并愿意適應(yīng)你的想法，以適應(yīng)內(nèi)核。 或者至少愿意證明你的想法是值得的。 記住，只要你愿意努力尋找一個(gè)正確的解決方案，那么錯(cuò)誤是可以接受的。

你的第一個(gè)補(bǔ)丁的答案可能僅僅是你應(yīng)該糾正的十幾件事情的列表，這是很正常的。 這并不意味著你的補(bǔ)丁不會(huì)被接受，這并不意味著對(duì)你個(gè)人不利。 只需更正針對(duì)您的修補(bǔ)程序提出的所有問題并重新發(fā)送。

內(nèi)核社區(qū)和公司結(jié)構(gòu)之間的差異

內(nèi)核社區(qū)的工作方式與大多數(shù)傳統(tǒng)企業(yè)開發(fā)環(huán)境不同。以下列出了您可以嘗試避免的問題：

關(guān)于您提出的更改要說的很好：

• “這解決了很多問題。”
• “這刪除了2000行代碼。”
• “這是一個(gè)解釋我想描述的東西的補(bǔ)丁。”
• “我測(cè)試了5種不同的架構(gòu)......”
• “這是一系列的小補(bǔ)丁...”
• “這增加了典型機(jī)器的性能......”

不好的事情，你應(yīng)該避免說：

• “我們?cè)贏IX/ptx/Solaris中這樣做，所以它一定是好的...”
• “我已經(jīng)這樣做了20年了，所以......”
• “這是我的公司賺錢所需要的”
• “這是為我們的企業(yè)產(chǎn)品線”。
• “這是我的1000頁的設(shè)計(jì)文件，描述了我的想法”
• “我已經(jīng)為此工作了6個(gè)月......”
• “這是一個(gè)5000行補(bǔ)丁...”
• “我重寫了當(dāng)前所有的爛攤子，這里是......”
• “我有一個(gè)最后期限，現(xiàn)在需要應(yīng)用這個(gè)補(bǔ)丁。”

內(nèi)核社區(qū)與大多數(shù)傳統(tǒng)的軟件工程工作環(huán)境不同的另一種方式是交互的不露面本質(zhì)。 使用電子郵件和irc作為溝通的主要形式的一個(gè)好處是沒有基于性別或種族的歧視。 Linux內(nèi)核的工作環(huán)境是接受女性和少數(shù)民族，因?yàn)槟阒皇且粋€(gè)電子郵件地址。 國(guó)際方面也有助于平衡比賽場(chǎng)地，因?yàn)槟悴荒芨鶕?jù)一個(gè)人的名字來猜測(cè)性別。 一個(gè)男人可能被命名為安德烈，一個(gè)女人可能被命名為帕特。 大多數(shù)在Linux內(nèi)核中工作并發(fā)表過意見的女性都有積極的經(jīng)驗(yàn)。

語言障礙會(huì)給一些不習(xí)慣英語的人造成問題。 為了在郵件列表中正確地得到想法，需要掌握好語言，因此建議您在發(fā)送郵件之前檢查您的郵件以確保它們有英文意義。

Break up your changes（細(xì)分你的改動(dòng)）

Linux內(nèi)核社區(qū)并不樂意同時(shí)接受大量的代碼。 這些變化需要適當(dāng)?shù)慕榻B，討論，并分解成微小的，單獨(dú)的部分。 這幾乎與公司習(xí)慣的做法完全相反。 您的建議也應(yīng)該在開發(fā)過程中盡早介紹，以便您可以收到有關(guān)您正在進(jìn)行的操作的反饋。 它也讓社區(qū)覺得你正在與他們合作，而不是簡(jiǎn)單地把他們當(dāng)作你的特征的傾倒地。 但是，不要一次發(fā)送50封電子郵件到郵件列表，你的補(bǔ)丁系列應(yīng)該幾乎全部都是小于這個(gè)時(shí)間的。

細(xì)分的理由如下：

1. 小補(bǔ)丁增加了您的補(bǔ)丁應(yīng)用的可能性，因?yàn)樗麄儾恍枰鄷r(shí)間或精力來驗(yàn)證正確性。 一個(gè)5線補(bǔ)丁可以由維護(hù)人員應(yīng)用幾乎一眼就可以看到。 但是，500行補(bǔ)丁可能需要幾個(gè)小時(shí)來檢查正確性（所花費(fèi)的時(shí)間與補(bǔ)丁的大小成指數(shù)成比例）。
   小的補(bǔ)丁也使得在出現(xiàn)問題時(shí)很容易進(jìn)行調(diào)試。 一個(gè)接一個(gè)地退出補(bǔ)丁要比在一個(gè)補(bǔ)丁被應(yīng)用之后解剖一個(gè)非常大的補(bǔ)丁容易得多（并且破壞了某些東西）。

2. 發(fā)送小補(bǔ)丁很重要，而且在提交補(bǔ)丁前要重寫和簡(jiǎn)化補(bǔ)丁（或簡(jiǎn)單地重新排序）。

這里是內(nèi)核開發(fā)者Al Viro的一個(gè)類比：

“Think of a teacher grading homework from a math student. The teacher does not want to see the student’s trials and errors before they came up with the solution. They want to see the cleanest, most elegant answer. A good student knows this, and would never submit her intermediate work before the final solution.

The same is true of kernel development. The maintainers and reviewers do not want to see the thought process behind the solution to the problem one is solving. They want to see a simple and elegant solution.”

在提出一個(gè)優(yōu)雅的解決方案和與社區(qū)一起工作并討論你未完成的工作之間保持平衡可能是一個(gè)挑戰(zhàn)。 因此，盡早獲得反饋意見以改進(jìn)工作是很好的做法，但是也可以將您的更改保留在可能已被接受的小塊中，即使您的整個(gè)任務(wù)現(xiàn)在還沒有準(zhǔn)備好。

也意識(shí)到，發(fā)送補(bǔ)丁包括未完成的補(bǔ)丁是不可接受的，并且將在稍后“修復(fù)”。

驗(yàn)證修補(bǔ)

隨著打破你的補(bǔ)丁，讓你的Linux社區(qū)知道他們?yōu)槭裁匆砑舆@個(gè)變化是非常重要的。 新功能必須被證明是必要和有用的。

記錄您的更改

在發(fā)送補(bǔ)丁時(shí)，請(qǐng)?zhí)貏e注意您在電子郵件中的文字內(nèi)容。 這些信息將成為修補(bǔ)程序的ChangeLog信息，并將保留給所有人看。 它應(yīng)該完整地描述補(bǔ)丁，包含：

• 為什么改變是必要的
• 補(bǔ)丁中的整體設(shè)計(jì)方法
• 實(shí)施細(xì)節(jié)
• 測(cè)試結(jié)果

有關(guān)這應(yīng)該是什么樣子的更多細(xì)節(jié)，請(qǐng)參閱文檔的ChangeLog部分：

• “完美的補(bǔ)丁”
  http://www.ozlabs.org/~akpm/stuff/tpp.txt

所有這些東西有時(shí)候很難做到。 完善這些實(shí)踐可能需要幾年的時(shí)間（如果有的話）。 這是一個(gè)持續(xù)的改善過程，需要很多的耐心和決心。 但是不要放棄，這是可能的。 以前有很多人做過，每個(gè)人都必須從現(xiàn)在開始。

感謝Paolo Ciarrocchi，他允許“Development Process”（https://lwn.net/Articles/94386/）部分基于他寫的文本，Randy Dunlap和Gerrit Huizenga提供了一些你所需要的東西 應(yīng)該也不應(yīng)該說。 也感謝Pat Mochel，Hanna Linder，Randy Dunlap，Kay Sievers，Vojtech Pavlik，Jan Kara，Josh Boyer，Kees Cook，Andrew Morton，Andi Kleen，Vadim Lobanov，Jesper Juhl，Adrian Bunk，Keri Harris，F(xiàn)rans Pop，David A Wheeler，Junio Hamano，Michael Kerrisk和Alex Shepard的評(píng)論，評(píng)論和貢獻(xiàn)。 沒有他們的幫助，這個(gè)文件是不可能的。

維護(hù)者：Greg Kroah-Hartman greg@kroah.com