如何參與linux 核心開發

如果想評論或更新本文的内容，請直接聯系原文檔的維護者。如果你使用英文

交流有困難的話，也可以向中文版維護者求助。如果本翻譯更新不及時或者翻

譯存在問題，請聯系中文版維護者。

英文版維護者： Greg Kroah-Hartman <[email protected]>

中文版維護者： 李陽 Li Yang <[email protected]>

中文版翻譯者： 李陽 Li Yang <[email protected]>

中文版校譯者： 鐘宇 TripleX Chung <[email protected]>

               陳琦 Maggie Chen <[email protected]>

               王聰 Wang Cong <[email protected]>

以下為正文

---------------------------------------------------------------------

如何參與Linux核心開發

---------------------

這是一篇将如何參與Linux核心開發的相關問題一網打盡的終極秘笈。它将指導你

成為一名Linux核心開發者，并且學會如何同Linux核心開發社群合作。它盡可能不

包括任何關于核心程式設計的技術細節，但會給你指引一條獲得這些知識的正确途徑。

如果這篇文章中的任何内容不再适用，請給文末列出的檔案維護者發送更新檔。

入門

----

你想了解如何成為一名Linux核心開發者？或者老闆吩咐你“給這個裝置寫個Linux

驅動程式”？這篇文章的目的就是教會你達成這些目标的全部訣竅，它将描述你需

要經過的流程以及給出如何同核心社群合作的一些提示。它還将試圖解釋核心社群

為何這樣運作。

Linux核心大部分是由C語言寫成的，一些體系結構相關的代碼用到了彙編語言。要

參與核心開發，你必須精通C語言。除非你想為某個架構開發底層代碼，否則你并

不需要了解（任何體系結構的）彙編語言。下面列舉的書籍雖然不能替代紮實的C

語言教育和多年的開發經驗，但如果需要的話，做為參考還是不錯的：

 - "The C Programming Language" by Kernighan and Ritchie [Prentice Hall]

   《C程式設計語言（第2版·新版）》（徐寶文 李志 譯）[機械工業出版社]

 - "Practical C Programming" by Steve Oualline [O'Reilly]

   《實用C語言程式設計（第三版）》（郭大海 譯）[中國電力出版社]

 - "C: A Reference Manual" by Harbison and Steele [Prentice Hall]

   《C語言參考手冊（原書第5版）》（邱仲潘 等譯）[機械工業出版社]

Linux核心使用GNU C和GNU工具鍊開發。雖然它遵循ISO C89标準，但也用到了一些

标準中沒有定義的擴充。核心是自給自足的C環境，不依賴于标準C庫的支援，是以

并不支援C标準中的部分定義。比如long long類型的大數除法和浮點運算就不允許

使用。有時候确實很難弄清楚核心對工具鍊的要求和它所使用的擴充，不幸的是目

前還沒有明确的參考資料可以解釋它們。請查閱gcc資訊頁（使用“info gcc”指令

顯示）獲得一些這方面資訊。

請記住你是在學習怎麼和已經存在的開發社群打交道。它由一群形形色色的人組成，

他們對代碼、風格和過程有着很高的标準。這些标準是在長期實踐中總結出來的，

适應于地理上分散的大型開發團隊。它們已經被很好得整理成檔，建議你在開發

之前盡可能多的學習這些标準，而不要期望别人來适應你或者你公司的行為方式。

法律問題

--------

Linux核心源代碼都是在GPL（通用公共許可證）的保護下釋出的。要了解這種許可

的細節請檢視源代碼主目錄下的COPYING檔案。如果你對它還有更深入問題請聯系

律師，而不要在Linux核心郵件組上提問。因為郵件組裡的人并不是律師，不要期

望他們的話有法律效力。

對于GPL的常見問題和解答，請通路以下連結：

http://www.gnu.org/licenses/gpl-faq.html

文檔

Linux核心代碼中包含有大量的文檔。這些文檔對于學習如何與核心社群互動有着

不可估量的價值。當一個新的功能被加入核心，最好把解釋如何使用這個功能的文

檔也放進核心。當核心的改動導緻面向使用者空間的接口發生變化時，最好将相關信

息或手冊頁(manpages)的更新檔發到[email protected]，以向手冊頁(manpages)

的維護者解釋這些變化。

以下是核心代碼中需要閱讀的文檔：

  README

    檔案簡要介紹了Linux核心的背景，并且描述了如何配置和編譯核心。核心的

    新使用者應該從這裡開始。

  Documentation/Changes

    檔案給出了用來編譯和使用核心所需要的最小軟體包清單。

  Documentation/CodingStyle

    描述Linux核心的代碼風格和理由。所有新代碼需要遵守這篇文檔中定義的規

    範。大多數維護者隻會接收符合規定的更新檔，很多人也隻會幫忙檢查符合風格

    的代碼。

  Documentation/SubmittingPatches

  Documentation/SubmittingDrivers

    這兩份文檔明确描述如何建立和發送更新檔，其中包括（但不僅限于)：

       - 郵件内容

       - 郵件格式

       - 選擇收件人

    遵守這些規定并不能保證送出成功（因為所有更新檔需要通過嚴格的内容和風格

    審查），但是忽視他們幾乎就意味着失敗。

    其他關于如何正确地生成更新檔的優秀文檔包括：

    "The Perfect Patch"

        http://userweb.kernel.org/~akpm/stuff/tpp.txt

    "Linux kernel patch submission format"

        http://linux.yyz.us/patch-format.html

  Documentation/stable_api_nonsense.txt

    論證核心為什麼特意不包括穩定的核心内部API，也就是說不包括像這樣的特

    性：

       - 子系統中間層（為了相容性？）

       - 在不同作業系統間易于移植的驅動程式

       - 減緩（甚至阻止）核心代碼的快速變化

    這篇文檔對于了解Linux的開發哲學至關重要。對于将開發平台從其他操作系

    統轉移到Linux的人來說也很重要。

  Documentation/SecurityBugs

    如果你認為自己發現了Linux核心的安全性問題，請根據這篇文檔中的步驟來

    提醒其他核心開發者并幫助解決這個問題。

  Documentation/ManagementStyle

    描述核心維護者的工作方法及其共有特點。這對于剛剛接觸核心開發（或者對

    它感到好奇）的人來說很重要，因為它解釋了很多對于核心維護者獨特行為的

    普遍誤解與迷惑。

  Documentation/stable_kernel_rules.txt

    解釋了穩定版核心釋出的規則，以及如何将改動放入這些版本的步驟。

  Documentation/kernel-docs.txt

    有助于核心開發的外部文檔清單。如果你在核心自帶的文檔中沒有找到你想找

    的内容，可以檢視這些文檔。

  Documentation/applying-patches.txt

    關于更新檔是什麼以及如何将它打在不同核心開發分支上的好介紹

核心還擁有大量從代碼自動生成的文檔。它包含核心内部API的全面介紹以及如何

妥善處理加鎖的規則。生成的文檔會放在 Documentation/DocBook/目錄下。在内

核源碼的主目錄中使用以下不同指令将會分别生成PDF、Postscript、HTML和手冊

頁等不同格式的文檔：

    make pdfdocs

    make psdocs

    make htmldocs

    make mandocs

如何成為核心開發者

------------------

如果你對Linux核心開發一無所知，你應該通路“Linux核心新手”計劃：

http://kernelnewbies.org

它擁有一個可以問各種最基本的核心開發問題的郵件清單（在提問之前一定要記得

查找已往的郵件，确認是否有人已經回答過相同的問題）。它還擁有一個可以獲得

實時回報的IRC聊天頻道，以及大量對于學習Linux核心開發相當有幫助的文檔。

網站簡要介紹了源代碼組織結構、子系統劃分以及目前正在進行的項目（包括核心

中的和單獨維護的）。它還提供了一些基本的幫助資訊，比如如何編譯核心和打補

丁。

如果你想加入核心開發社群并協助完成一些任務，卻找不到從哪裡開始，可以通路

“Linux核心房管員”計劃：

http://kernelnewbies.org/KernelJanitors

這是極佳的起點。它提供一個相對簡單的任務清單，列出核心代碼中需要被重新

整理或者改正的地方。通過和負責這個計劃的開發者們一同工作，你會學到将更新檔

內建進核心的基本原理。如果還沒有決定下一步要做什麼的話，你還可能會得到方

向性的指點。

如果你已經有一些現成的代碼想要放到核心中，但是需要一些幫助來使它們擁有正

确的格式。請通路“核心導師”計劃。這個計劃就是用來幫助你完成這個目标的。它

是一個郵件清單，位址如下：

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

在真正動手修改核心代碼之前，了解要修改的代碼如何運作是必需的。要達到這個

目的，沒什麼辦法比直接讀代碼更有效了（大多數花招都會有相應的注釋），而且

一些特制的工具還可以提供幫助。例如，“Linux代碼交叉引用”項目就是一個值得

特别推薦的幫助工具，它将源代碼顯示在有編目和索引的網頁上。其中一個更新及

時的核心源碼庫，可以通過以下位址通路：

http://sosdg.org/~coywolf/lxr/

開發流程

目前Linux核心開發流程包括幾個“主核心分支”和很多子系統相關的核心分支。這

些分支包括：

  - 2.6.x主核心源碼樹

  - 2.6.x.y -stable核心源碼樹

  - 2.6.x -git核心更新檔集

  - 2.6.x -mm核心更新檔集

  - 子系統相關的核心源碼樹和更新檔集

2.6.x核心主源碼樹

-----------------

2.6.x核心是由Linus Torvalds（Linux的創造者）親自維護的。你可以在

kernel.org網站的pub/linux/kernel/v2.6/目錄下找到它。它的開發遵循以下步

驟：

  - 每當一個新版本的核心被釋出，為期兩周的內建視窗将被打開。在這段時間裡

    維護者可以向Linus送出大段的修改，通常這些修改已經被放到-mm核心中幾個

    星期了。送出大量修改的首選方式是使用git工具（核心的代碼版本管理工具

    ，更多的資訊可以在http://git.or.cz/擷取），不過使用普通更新檔也是可以

    的。

  - 兩個星期以後-rc1版本核心釋出。之後隻有不包含可能影響整個核心穩定性的

    新功能的更新檔才可能被接受。請注意一個全新的驅動程式（或者檔案系統）有

    可能在-rc1後被接受是因為這樣的修改完全獨立，不會影響其他的代碼，是以

    沒有造成核心退步的風險。在-rc1以後也可以用git向Linus送出更新檔，不過所

    有的更新檔需要同時被發送到相應的公衆郵件清單以征詢意見。

  - 當Linus認為目前的git源碼樹已經達到一個合理健全的狀态足以釋出供人測試

    時，一個新的-rc版本就會被釋出。計劃是每周都釋出新的-rc版本。

  - 這個過程一直持續下去直到核心被認為達到足夠穩定的狀态，持續時間大概是

    6個星期。

  - 以下位址跟蹤了在每個-rc釋出中發現的退步清單：

    http://kernelnewbies.org/known_regressions

關于核心釋出，值得一提的是Andrew Morton在linux-kernel郵件清單中如是說：

“沒有人知道新核心何時會被釋出，因為釋出是根據已知bug的情況來決定

的，而不是根據一個事先制定好的時間表。”

2.6.x.y -stable（穩定版）核心源碼樹

-----------------------------------

由4個數字組成的核心版本号說明此核心是-stable版本。它們包含基于2.6.x版本

核心的相對較小且至關重要的修補，這些修補針對安全性問題或者嚴重的核心退步。

這種版本的核心适用于那些期望獲得最新的穩定版核心并且不想參與測試開發版或

者實驗版的使用者。

如果沒有2.6.x.y版本核心存在，那麼最新的2.6.x版本核心就相當于是目前的穩定

版核心。

2.6.x.y版本由“穩定版”小組（郵件位址<[email protected]>）維護，一般隔周發

布新版本。

核心源碼中的Documentation/stable_kernel_rules.txt檔案具體描述了可被穩定

版核心接受的修改類型以及釋出的流程。

2.6.x -git更新檔集

----------------

Linus的核心源碼樹的每日快照，這個源碼樹是由git工具管理的（由此得名）。這

些更新檔通常每天更新以反映Linus的源碼樹的最新狀态。它們比-rc版本的核心源碼

樹更具試驗性質，因為這個更新檔集是全自動生成的，沒有任何人來确認其是否真正

健全。

2.6.x -mm更新檔集

---------------

這是由Andrew Morton維護的試驗性核心更新檔集。Andrew将所有子系統的核心源碼

和更新檔拼湊到一起，并且加入了大量從linux-kernel郵件清單中采集的更新檔。這個

源碼樹是新功能和更新檔的試煉場。當更新檔在-mm更新檔集裡證明了其價值以後Andrew

或者相應子系統的維護者會将更新檔發給Linus以便內建進主核心源碼樹。

在将所有新更新檔發給Linus以內建到主核心源碼樹之前，我們非常鼓勵先把這些補

丁放在-mm版核心源碼樹中進行測試。

這些核心版本不适合在需要穩定運作的系統上運作，因為運作它們比運作任何其他

核心分支都更具有風險。

如果你想為核心開發程序提供幫助，請嘗試并使用這些核心版本，并在

linux-kernel郵件清單中提供回報，告訴大家你遇到了問題還是一切正常。

通常-mm版更新檔集不光包括這些額外的試驗性更新檔，還包括釋出時-git版主源碼樹

中的改動。

-mm版核心沒有固定的釋出周期，但是通常在每兩個-rc版核心釋出之間都會有若幹

個-mm版核心釋出（一般是1至3個）。

子系統相關核心源碼樹和更新檔集

----------------------------

相當一部分核心子系統開發者會公開他們自己的開發源碼樹，以便其他人能了解内

核的不同領域正在發生的事情。如上所述，這些源碼樹會被內建到-mm版本核心中。

下面是目前可用的一些核心源碼樹的清單：

  通過git管理的源碼樹：

    - Kbuild開發源碼樹， Sam Ravnborg <[email protected]>

git.kernel.org:/pub/scm/linux/kernel/git/sam/kbuild.git

    - ACPI開發源碼樹, Len Brown <[email protected]>

git.kernel.org:/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6.git

    - 塊裝置開發源碼樹, Jens Axboe <[email protected]>

git.kernel.org:/pub/scm/linux/kernel/git/axboe/linux-2.6-block.git

    - DRM開發源碼樹, Dave Airlie <[email protected]>

git.kernel.org:/pub/scm/linux/kernel/git/airlied/drm-2.6.git

    - ia64開發源碼樹, Tony Luck <[email protected]>

git.kernel.org:/pub/scm/linux/kernel/git/aegl/linux-2.6.git

    - ieee1394開發源碼樹, Jody McIntyre <[email protected]>

git.kernel.org:/pub/scm/linux/kernel/git/scjody/ieee1394.git

    - infiniband開發源碼樹, Roland Dreier <[email protected]>

git.kernel.org:/pub/scm/linux/kernel/git/roland/infiniband.git

    - libata開發源碼樹, Jeff Garzik <[email protected]>

git.kernel.org:/pub/scm/linux/kernel/git/jgarzik/libata-dev.git

    - 網絡驅動程式開發源碼樹, Jeff Garzik <[email protected]>

git.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git

    - pcmcia開發源碼樹, Dominik Brodowski <[email protected]>

git.kernel.org:/pub/scm/linux/kernel/git/brodo/pcmcia-2.6.git

    - SCSI開發源碼樹, James Bottomley <[email protected]>

git.kernel.org:/pub/scm/linux/kernel/git/jejb/scsi-misc-2.6.git

  使用quilt管理的更新檔集：

    - USB, PCI, 驅動程式核心和I2C, Greg Kroah-Hartman <[email protected]>

kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/

    - x86-64, 部分i386, Andi Kleen <[email protected]>

ftp.firstfloor.org:/pub/ak/x86_64/quilt/

  其他核心源碼樹可以在http://git.kernel.org的清單中和MAINTAINERS檔案裡

  找到。

報告bug

-------

bugzilla.kernel.org是Linux核心開發者們用來跟蹤核心Bug的網站。我們鼓勵用

戶在這個工具中報告找到的所有bug。如何使用核心bugzilla的細節請通路：

http://test.kernel.org/bugzilla/faq.html

核心源碼主目錄中的REPORTING-BUGS檔案裡有一個很好的模闆。它指導使用者如何報

告可能的核心bug以及需要提供哪些資訊來幫助核心開發者們找到問題的根源。

利用bug報告

-----------

練習核心開發技能的最好辦法就是修改其他人報告的bug。你不光可以幫助核心變

得更加穩定，還可以學會如何解決實際問題進而提高自己的技能，并且讓其他開發

者感受到你的存在。修改bug是赢得其他開發者贊譽的最好辦法，因為并不是很多

人都喜歡浪費時間去修改别人報告的bug。

要嘗試修改已知的bug，請通路http://bugzilla.kernel.org網址。如果你想獲得

最新bug的通知，可以訂閱bugme-new郵件清單（隻有新的bug報告會被寄到這裡）

或者訂閱bugme-janitor郵件清單（所有bugzilla的變動都會被寄到這裡）。

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

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

郵件清單

正如上面的文檔所描述，大多數的骨幹核心開發者都加入了Linux Kernel郵件列

表。如何訂閱和退訂清單的細節可以在這裡找到：

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

網上很多地方都有這個郵件清單的存檔(archive)。可以使用搜尋引擎來找到這些

存檔。比如：

http://dir.gmane.org/gmane.linux.kernel

在發信之前，我們強烈建議你先在存檔中搜尋你想要讨論的問題。很多已經被詳細

讨論過的問題隻在郵件清單的存檔中可以找到。

大多數核心子系統也有自己獨立的郵件清單來協調各自的開發工作。從

MAINTAINERS檔案中可以找到不同話題對應的郵件清單。

很多郵件清單架設在kernel.org伺服器上。這些清單的資訊可以在這裡找到：

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

在使用這些郵件清單時，請記住保持良好的行為習慣。下面的連結提供了與這些列

表（或任何其它郵件清單）交流的一些簡單規則，雖然内容有點濫竽充數。

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

當有很多人回複你的郵件時，郵件的抄送清單會變得很長。請不要将任何人從抄送

清單中删除，除非你有足夠的理由這麼做。也不要隻回複到郵件清單。請習慣于同

一封郵件接收兩次（一封來自發送者一封來自郵件清單），而不要試圖通過添加一

些奇特的郵件頭來解決這個問題，人們不會喜歡的。

記住保留你所回複内容的上下文和源頭。在你回複郵件的頂部保留“某某某說到……”

這幾行。将你的評論加在被引用的段落之間而不要放在郵件的頂部。

如果你在郵件中附帶更新檔，請确認它們是可以直接閱讀的純文字（如

Documentation/SubmittingPatches文檔中所述）。核心開發者們不希望遇到附件

或者被壓縮了的更新檔。隻有這樣才能保證他們可以直接評論你的每行代碼。請確定

你使用的郵件發送程式不會修改空格和制表符。一個防範性的測試方法是先将郵件

發送給自己，然後自己嘗試是否可以順利地打上收到的更新檔。如果測試不成功，請

調整或者更換你的郵件發送程式直到它正确工作為止。

總而言之，請尊重其他的郵件清單訂閱者。

同核心社群合作

核心社群的目标就是提供盡善盡美的核心。是以當你送出更新檔期望被接受進核心的

時候，它的技術價值以及其他方面都将被評審。那麼你可能會得到什麼呢？

  - 批評

  - 評論

  - 要求修改

  - 要求證明修改的必要性

  - 沉默

要記住，這些是把更新檔放進核心的正常情況。你必須學會聽取對更新檔的批評和評論，

從技術層面評估它們，然後要麼重寫你的更新檔要麼簡明扼要地論證修改是不必要

的。如果你發的郵件沒有得到任何回應，請過幾天後再試一次，因為有時信件會湮

沒在茫茫信海中。

你不應該做的事情：

  - 期望自己的更新檔不受任何質疑就直接被接受

  - 翻臉

  - 忽略别人的評論

  - 沒有按照别人的要求做任何修改就重新送出

在一個努力追尋最好技術方案的社群裡，對于一個更新檔有多少好處總會有不同的見

解。你必須要抱着合作的态度，願意改變自己的觀點來适應核心的風格。或者至少

願意去證明你的想法是有價值的。記住，犯錯誤是允許的，隻要你願意朝着正确的

方案去努力。

如果你的第一個更新檔換來的是一堆修改建議，這是很正常的。這并不代表你的更新檔

不會被接受，也不意味着有人和你作對。你隻需要改正所有提出的問題然後重新發

送你的更新檔。

核心社群和公司文化的差異

------------------------

核心社群的工作模式同大多數傳統公司開發隊伍的工作模式并不相同。下面這些例

子，可以幫助你避免某些可能發生問題：

  用這些話介紹你的修改提案會有好處：

    - 它同時解決了多個問題

    - 它删除了2000行代碼

    - 這是更新檔，它已經解釋了我想要說明的

    - 我在5種不同的體系結構上測試過它……

    - 這是一系列小更新檔用來……

    - 這個修改提高了普通機器的性能……

  應該避免如下的說法：

    - 我們在AIX/ptx/Solaris就是這麼做的，是以這麼做肯定是好的……

    - 我做這行已經20年了，是以……

    - 為了我們公司賺錢考慮必須這麼做

    - 這是我們的企業産品線所需要的

    - 這裡是描述我觀點的1000頁設計文檔

    - 這是一個5000行的更新檔用來……

    - 我重寫了現在亂七八糟的代碼，這就是……

    - 我被規定了最後期限，是以這個更新檔需要立刻被接受

另外一個核心社群與大部分傳統公司的軟體開發隊伍不同的地方是無法面對面地交

流。使用電子郵件和IRC聊天工具做為主要溝通工具的一個好處是性别和種族歧視

将會更少。Linux核心的工作環境更能接受婦女和少數族群，因為每個人在别人眼

裡隻是一個郵件位址。國際化也幫助了公平的實作，因為你無法通過姓名來判斷人

的性别。男人有可能叫李麗，女人也有可能叫王剛。大多數在Linux核心上工作過

并表達過看法的女性對在linux上工作的經曆都給出了正面的評價。

對于一些不習慣使用英語的人來說，語言可能是一個引起問題的障礙。在郵件清單

中要正确地表達想法必需良好地掌握語言，是以建議你在發送郵件之前最好檢查一

下英文寫得是否正确。

拆分修改

Linux核心社群并不喜歡一下接收大段的代碼。修改需要被恰當地介紹、讨論并且

拆分成獨立的小段。這幾乎完全和公司中的習慣背道而馳。你的想法應該在開發最

開始的階段就讓大家知道，這樣你就可以及時獲得對你正在進行的開發的回報。這

樣也會讓社群覺得你是在和他們協作，而不是僅僅把他們當作傾銷新功能的對象。

無論如何，你不要一次性地向郵件清單發送50封信，你的更新檔序列應該永遠用不到

這麼多。

将更新檔拆開的原因如下：

1) 小的更新檔更有可能被接受，因為它們不需要太多的時間和精力去驗證其正确性。

   一個5行的更新檔，可能在維護者看了一眼以後就會被接受。而500行的更新檔則

   需要數個小時來審查其正确性（所需時間随更新檔大小增加大約呈指數級增長）。

   當出了問題的時候，小的更新檔也會讓調試變得非常容易。一個一個更新檔地回溯

   将會比仔細剖析一個被打上的大更新檔（這個更新檔破壞了其他東西）容易得多。

2）不光發送小的更新檔很重要，在送出之前重新編排、化簡（或者僅僅重新排列）

   更新檔也是很重要的。

這裡有核心開發者Al Viro打的一個比方：

“想象一個老師正在給學生批改數學作業。老師并不希望看到學生為了得

到正确解法所進行的嘗試和産生的錯誤。他希望看到的是最幹淨最優雅的

解答。好學生了解這點，絕不會把最終解決之前的中間方案送出上去。”

核心開發也是這樣。維護者和評審者不希望看到一個人在解決問題時的思

考過程。他們隻希望看到簡單和優雅的解決方案。

直接給出一流的解決方案，和社群一起協作讨論尚未完成的工作，這兩者之間似乎

很難找到一個平衡點。是以最好盡早開始收集有利于你進行改進的回報；同時也要

保證修改分成很多小塊，這樣在整個項目都準備好被包含進核心之前，其中的一部

分可能會先被接收。

必須了解這樣做是不可接受的：試圖将未完成的工作送出進核心，然後再找時間修

複。

證明修改的必要性

除了将更新檔拆成小塊，很重要的一點是讓Linux社群了解他們為什麼需要這樣修改。

你必須證明新功能是有人需要的并且是有用的。

記錄修改

當你發送更新檔的時候，需要特别留意郵件正文的内容。因為這裡的資訊将會做為補

丁的修改記錄(ChangeLog)，會被一直保留以備大家查閱。它需要完全地描述更新檔，

包括：

  - 為什麼需要這個修改

  - 更新檔的總體設計

  - 實作細節

  - 測試結果

想了解它具體應該看起來像什麼，請查閱以下文檔中的“ChangeLog”章節：

  “The Perfect Patch”

   http://userweb.kernel.org/~akpm/stuff/tpp.txt

這些事情有時候做起來很難。要在任何方面都做到完美可能需要好幾年時間。這是

一個持續提高的過程，它需要大量的耐心和決心。隻要不放棄，你一定可以做到。

很多人已經做到了，而他們都曾經和現在的你站在同樣的起點上。

感謝Paolo Ciarrocchi允許“開發流程”部分基于他所寫的文章

(http://www.kerneltravel.net/newbie/2.6-development_process)，感謝Randy

Dunlap和Gerrit Huizenga完善了應該說和不該說的清單。感謝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, Frans Pop, David A. Wheeler, Junio Hamano, Michael

Kerrisk和Alex Shepard的評審、建議和貢獻。沒有他們的幫助，這篇文檔是不可

能完成的。

作者：warm3snow

出處：http://www.cnblogs.com/informatics/

本文版權歸作者和部落格園共有，歡迎轉載，但未經作者同意必須在文章頁面給出原文連接配接，否則保留追究法律責任的權利。