原文

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

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

介紹

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

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

• “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標準丛肮，但它使用了許多標準中沒有的擴展功能腾供。 內(nèi)核是一個獨立的C環(huán)境伴鳖，不依賴于標準C庫，因此C標準的某些部分不被支持搞疗。 任意長分歧和浮點是不允許的须肆。 有時難以理解內(nèi)核對工具鏈和它所使用的擴展的假設(shè)豌汇，不幸的是沒有明確的參考拒贱。 請檢查gcc info pages（info gcc）的一些信息。

請記住闸天，您正試圖學(xué)習(xí)如何與現(xiàn)有的開發(fā)社區(qū)合作苞氮。 它是一個多元化的人群笼吟，具有高標準的編碼抛姑，風(fēng)格和程序定硝。 隨著時間的推移蔬啡，這些標準已經(jīng)被創(chuàng)造出來，基于他們發(fā)現(xiàn)對于這樣一個地理上分散的大型團隊來說最好的工作沟绪。 盡可能提前了解這些標準绽慈，因為這些標準是有據(jù)可查的; 不要指望人們適應(yīng)你或你公司的做事方式。

法律問題

Linux內(nèi)核源代碼是在GPL下發(fā)布的搜贤。 有關(guān)許可證的詳細信息仪芒，請參閱源代碼樹主目錄中的COPYING文件掂名。 如果您有關(guān)于許可證的進一步問題哟沫，請聯(lián)系律師南用，而不要在Linux內(nèi)核郵件列表上詢問掏湾。 郵件列表上的人不是律師融击，你不應(yīng)該依賴他們在法律事務(wù)上的陳述尊浪。

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

文檔

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

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

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

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

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

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

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

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

所有這些文件可以通過運行生成PDF或HTML：

make pdfdocs
make htmldocs

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

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

make latexdocs
make epubdocs

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

Becoming A Kernel Developer

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

https://kernelnewbies.org

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

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

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

https://kernelnewbies.org/KernelJanitors

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

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

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

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

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

開發(fā)過程

Linux內(nèi)核開發(fā)過程目前由幾個不同的主內(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維護，可以在pub/linux/kernel/v4.x/目錄下的https://kernel.org上找到甜孤。其發(fā)展過程如下：

• 只要一個新的內(nèi)核被發(fā)布协饲，兩個星期的窗口就會被打開畏腕，在這段時間里，維護者可以向Linus提交大的差異茉稠，通常是已經(jīng)包含在-next內(nèi)核中幾個星期的補丁描馅。提交重大更改的首選方法是使用git（內(nèi)核的源代碼管理工具，更多信息可以在https://git-scm.com/找到）而线，但是普通的補丁也很好铭污。
• 兩個星期后，一個-rc1內(nèi)核被釋放膀篮，重點在于使得新內(nèi)核盡可能堅如磐石】隽梗現(xiàn)在大部分補丁都應(yīng)該修復(fù)一個回歸。一直存在的錯誤不是回歸各拷，所以只有在重要的時候才推動這些修復(fù)刁绒。請注意，在-rc1之后可能會接受一個全新的驅(qū)動程序（或文件系統(tǒng)）烤黍，因為只要更改是自包含的知市，并且不會影響代碼之外的區(qū)域添加。在發(fā)布-rc1之后速蕊，可以使用git將修補程序發(fā)送給Linus嫂丙，但是修補程序也需要發(fā)送到公共郵件列表以供審查。
• 每當Linus認為當前的git樹處于一個合理穩(wěn)定的狀態(tài)规哲，足以進行測試時跟啤，就會發(fā)布一個新的-rc。目標是每周發(fā)布一個新的-rc內(nèi)核唉锌。
• 進程一直持續(xù)到內(nèi)核被認為是“準備就緒”隅肥，這個過程應(yīng)該持續(xù)大約6個星期。

值得一提的是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)核袄简。 它們包含相對較小和重要的安全問題修復(fù)或在給定的4.x內(nèi)核中發(fā)現(xiàn)的顯著回退腥放。

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

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

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

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

4.x -git patches

這些是Linus內(nèi)核樹的每日快照良漱，這些快照是在git存儲庫（因此得名）中管理的舞虱。這些補丁通常每天發(fā)布，代表Linus樹的當前狀態(tài)母市。 它們比-rc內(nèi)核更具實驗性矾兜，因為它們是自動生成的，不用粗略一眼就能看出它們是否理智患久。

Subsystem Specific kernel trees and patches

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

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

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

4.x -next kernel tree for integration tests

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

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

這樣缨伊，下一個內(nèi)核就會給出一個總結(jié)性的展望摘刑，看看下一個合并期間將會進入主線內(nèi)核的內(nèi)容。 冒險的測試者非常歡迎運行時測試-next內(nèi)核刻坊。

Bug Reporting

https://bugzilla.kernel.org是Linux內(nèi)核開發(fā)者跟蹤內(nèi)核錯誤的地方枷恕。 鼓勵用戶報告他們在這個工具中找到的所有錯誤。 有關(guān)如何使用內(nèi)核bugzilla的詳細信息谭胚，請參閱：

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

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

Managing bug reports

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

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

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)如何訂閱和取消訂閱的詳細信息，請訪問：

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

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

大多數(shù)單獨的內(nèi)核子系統(tǒng)也都有自己的獨立郵件列表，他們在這里進行開發(fā)工作硼莽。 請參閱MAINTAINERS文件以獲取這些列表針對不同組的列表庶溶。

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

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

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

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

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

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

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

最重要的是甥雕，請記住尊重其他用戶踩身。

Working with the community

內(nèi)核社區(qū)的目標是提供最好的內(nèi)核。 當你提交一個可以接受的補丁的時候社露，將會對它的技術(shù)特性和那些單獨的補丁進行評估挟阻。 那么，你應(yīng)該期待什么峭弟？

• 批評
• 注釋
• 要求改變
• 請求理由
• 安靜

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

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

• 希望您的補丁能夠毫無疑問地被接受
• 變得防守
• 忽略評論
• 重新提交修補程序而不進行任何請求的更改

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

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

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

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

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

• “這解決了很多問題脖祈∷敛叮”
• “這刪除了2000行代碼「歉撸”
• “這是一個解釋我想描述的東西的補丁慎陵。”
• “我測試了5種不同的架構(gòu)......”
• “這是一系列的小補丁...”
• “這增加了典型機器的性能......”

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

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

內(nèi)核社區(qū)與大多數(shù)傳統(tǒng)的軟件工程工作環(huán)境不同的另一種方式是交互的不露面本質(zhì)刀疙。 使用電子郵件和irc作為溝通的主要形式的一個好處是沒有基于性別或種族的歧視舶赔。 Linux內(nèi)核的工作環(huán)境是接受女性和少數(shù)民族，因為你只是一個電子郵件地址谦秧。 國際方面也有助于平衡比賽場地竟纳，因為你不能根據(jù)一個人的名字來猜測性別。 一個男人可能被命名為安德烈油够，一個女人可能被命名為帕特蚁袭。 大多數(shù)在Linux內(nèi)核中工作并發(fā)表過意見的女性都有積極的經(jīng)驗。

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

Break up your changes（細分你的改動）

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

細分的理由如下：

1. 小補丁增加了您的補丁應(yīng)用的可能性肢簿，因為他們不需要太多時間或精力來驗證正確性。 一個5線補丁可以由維護人員應(yīng)用幾乎一眼就可以看到蜻拨。 但是池充，500行補丁可能需要幾個小時來檢查正確性（所花費的時間與補丁的大小成指數(shù)成比例）。
   小的補丁也使得在出現(xiàn)問題時很容易進行調(diào)試缎讼。 一個接一個地退出補丁要比在一個補丁被應(yīng)用之后解剖一個非常大的補丁容易得多（并且破壞了某些東西）收夸。

2. 發(fā)送小補丁很重要，而且在提交補丁前要重寫和簡化補缎莸印（或簡單地重新排序）咱圆。

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

“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.”

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

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

驗證修補

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

記錄您的更改

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

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

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

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

所有這些東西有時候很難做到任岸。 完善這些實踐可能需要幾年的時間（如果有的話）。 這是一個持續(xù)的改善過程狡刘，需要很多的耐心和決心享潜。 但是不要放棄，這是可能的嗅蔬。 以前有很多人做過剑按，每個人都必須從現(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的評論，評論和貢獻沈善。 沒有他們的幫助乡数，這個文件是不可能的。

維護者：Greg Kroah-Hartman greg@kroah.com