HOWTO do Linux kernel development - take 3 (中文版，轉(zhuǎn)自CLF，譯者：zhllg)

leviathan.alan

譯者：張樂 robert_AT_thizlinux_DOT_com
原作：Greg KH
譯注：本文依據(jù)take 3翻譯，應(yīng)該不會(huì)再有大的改動(dòng)了，如果有本文會(huì)隨時(shí)更新
時(shí)間倉促，恐難免錯(cuò)漏，歡迎指正
原文：http://permalink.gmane.org/gmane.linux.kernel/349656 (轉(zhuǎn)貼說明：也可以在內(nèi)核源代碼目錄下的Documentation/HOWTO找到本文英文版)
譯文：

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

HOWTO do Linux kernel development
---------------------------------

這篇文章將是這個(gè)話題的最權(quán)威的文檔。它將教你如何成為一個(gè)Linux內(nèi)核開發(fā)者以及學(xué)會(huì)如何和Linux內(nèi)核社區(qū)一起工作。它不包含任何有關(guān)內(nèi)核編程的技術(shù)細(xì)節(jié)，但是會(huì)幫你在這方面指明方向。

如果這篇文檔里任何部分已經(jīng)過時(shí)，請把補(bǔ)丁發(fā)送給本文的維護(hù)者，他的聯(lián)系方式列在本文檔的末尾。

介紹
---

好了，你想成知道如何成為一個(gè)Linux內(nèi)核開發(fā)者么？或者你的老板告訴你，“去為這個(gè)設(shè)備寫一個(gè)Linux驅(qū)動(dòng)�！斑@篇文檔的目的，就是通過描述你需要經(jīng)歷的過程和提示你如何和社區(qū)一起工作，來教給你為達(dá)到這些目的所需要知道的所有知識。本文也嘗試解釋社區(qū)為什么這樣工作的一些原因。

內(nèi)核幾乎全是用C寫成的，有一些架構(gòu)相關(guān)的部分是用匯編語言寫成的。熟練掌握C語言是內(nèi)核開發(fā)的必備條件。匯編語言（任何架構(gòu)）的了解不是必須的，除非你準(zhǔn)備做某個(gè)架構(gòu)的底層開發(fā)。雖然下面這些書不能完全代替扎實(shí)的C語言教學(xué)和/或者成年累月的經(jīng)驗(yàn)，他們還是不錯(cuò)的參考，如果用得著的話：
- "The C Programming Language" 作者： Kernighan and Ritchie [Prentice Hall]
- "Practical C Programming" 作者： Steve Oualline [O'Reilly]


內(nèi)核是用 GNU C 和 GNU 工具鏈寫成的。雖然它符合 ISO C89 標(biāo)準(zhǔn)，它還是使用了一些標(biāo)準(zhǔn)中沒有的擴(kuò)展。內(nèi)核是自稱體系的 C 環(huán)境，它并不依賴標(biāo)準(zhǔn)C庫，所以某些C語言標(biāo)準(zhǔn)是不支持的。任意長度long long類型除法和浮點(diǎn)數(shù)是不被允許的。有時(shí)候會(huì)很難理解內(nèi)核對于它所使用的工具鏈和擴(kuò)展的假定，而且不幸的是也沒有關(guān)于它們的絕對的參考。請查閱gcc 的info頁(`info gcc`)以獲取有關(guān)信息。

請記住你是在嘗試學(xué)習(xí)如何與已經(jīng)存在的開發(fā)社區(qū)一起工作。這是一群成分復(fù)雜的人們，他們對于代碼，風(fēng)格和步驟有高的標(biāo)準(zhǔn)。這些標(biāo)準(zhǔn)是經(jīng)過時(shí)間檢驗(yàn)的。他們發(fā)現(xiàn)遵循這些標(biāo)準(zhǔn)對于這樣一個(gè)大規(guī)模的且地理上分散的團(tuán)隊(duì)是最佳的選擇。嘗試提前學(xué)習(xí)盡可能多的有關(guān)這些標(biāo)準(zhǔn)的知識，因?yàn)樗鼈兌加泻芎玫奈臋n；不要期望別人會(huì)遵照你或者你公司的行事方式。

法律問題
------

Linux內(nèi)核源代碼依照GPL發(fā)布。請參考源代碼樹下的COPYING文件，以獲取有關(guān)這個(gè)許可證的詳細(xì)信息。如果你對這個(gè)許可證有疑問，請聯(lián)系你的律師，不要在Linux內(nèi)核郵件列表里詢問。郵件列表里的人們不是律師，你不應(yīng)該依賴于他們對于法律問題的解釋。

欲了解有關(guān)GPL的常見問題和答案，請看：
http://www.gnu.org/licenses/gpl-faq.html

文檔
---

Linux內(nèi)核源代碼樹有很多文檔，它們對于學(xué)習(xí)如何與內(nèi)核社區(qū)交流來說有不可估量的價(jià)值。當(dāng)新的功能加進(jìn)內(nèi)核的時(shí)候，通常建議作者把解釋這個(gè)新功能的文檔也加進(jìn)內(nèi)核。如果一個(gè)內(nèi)核變動(dòng)導(dǎo)致了內(nèi)核對用戶空間界面的改變，建議你把這個(gè)信息或者一個(gè)解釋了這個(gè)變動(dòng)的manpage的補(bǔ)丁發(fā)送給手冊頁的維護(hù)者 mtk-manpages@gmx.net。

這里有一個(gè)內(nèi)核源代碼樹里需要閱讀的文件列表：
README
這個(gè)文件簡單介紹了Linux內(nèi)核的背景，并描述了配置和編譯內(nèi)核需要做哪些事情。內(nèi)核新手應(yīng)該從這里開始。

Documentation/Changes
這個(gè)文件介紹了成功編譯和運(yùn)行內(nèi)核所需要各種不同軟件的列表。

Documentation/CodingStyle
這個(gè)文件描述了Linux內(nèi)核代碼風(fēng)格，還有背后的一些原因。所有的新代碼的要符合這個(gè)文檔里的準(zhǔn)則。大多數(shù)維護(hù)者只會(huì)接受符合這些規(guī)則的補(bǔ)丁，很多人只看符合正確風(fēng)格的代碼。

Documentation/SubmittingPatches
Documentation/SubmittingDrivers
這些文件非常詳細(xì)的介紹了如何成功的創(chuàng)建和發(fā)送一個(gè)補(bǔ)丁，包括（但不限于）：
－Email內(nèi)容
－Email格式
－發(fā)送給誰
遵守所有這些規(guī)則并不能保證成功（對所有的補(bǔ)丁都需要進(jìn)行內(nèi)容和風(fēng)格的詳細(xì)檢查），但是不遵守這些規(guī)則就一定不會(huì)成功。

其他關(guān)于如何創(chuàng)建補(bǔ)丁的很好的文章有：
“The Perfect Patch"
http://www.zip.com.au/~akpm/linux/patches/stuff/tpp.txt
"Linux kernle patch submission format"
http://linux.yyz.us/patch-format.html

Documentation/stable_api_nonsense.txt
這個(gè)文件解釋了有意識的決定－不在內(nèi)核里使用穩(wěn)定的API－的原因，包括：
－子系統(tǒng)分隔層（為了兼容？）
－操作系統(tǒng)之間的驅(qū)動(dòng)可移植性
－緩和（或者阻止）內(nèi)核源代碼樹的急速變動(dòng)
這個(gè)文檔對于了解Linux的開發(fā)哲學(xué)是非常關(guān)鍵的，對于由開發(fā)其他操作系統(tǒng)轉(zhuǎn)而開發(fā)Linux人也是很重要的。

Documentation/SecurityBugs
如果你感覺到你發(fā)現(xiàn)了Linux內(nèi)核里的一個(gè)安全問題，請遵照這個(gè)文檔里所描述的步驟來提醒內(nèi)核開發(fā)者，并幫助解決問題。

Documentation/ManagementStyle
這個(gè)文檔描述了Linux內(nèi)核維護(hù)者如何運(yùn)作，以及他們?yōu)槭裁催@樣做。它對于任何內(nèi)核開發(fā)新手（或者任何對本話題感興趣的人）來說是非常重要的。因?yàn)樗�解釋了一些慣有的錯(cuò)誤概念，可解決有關(guān)內(nèi)核維護(hù)者獨(dú)特行為的疑惑。

Documentation/stable_kernel_rules.txt
本文件描述了穩(wěn)定版本內(nèi)核釋出的規(guī)則，還有如果你想對其中的一個(gè)版本做一些改動(dòng)應(yīng)該做些什么。

Documentation/kernel-docs.txt
一個(gè)有關(guān)內(nèi)核開發(fā)的外部文檔的列表。如果你在內(nèi)核內(nèi)部文檔里沒有找到你要找的東西，你可以參考這個(gè)列表。

Documentation/applying-patches.txt
介紹了對于什么是補(bǔ)丁，以及如何應(yīng)用補(bǔ)丁于不同的內(nèi)核開發(fā)分支。

內(nèi)核也有很多可以從源代碼自動(dòng)產(chǎn)生的文檔。這包括內(nèi)核內(nèi)部API的全面描述，有關(guān)如何處理好鎖定的規(guī)則。這些文檔會(huì)被創(chuàng)建于 Documentation/DocBook/文件夾中。在內(nèi)核主源碼樹中通過運(yùn)行下面的命令可以創(chuàng)建出PDF，Postscript，HTML和 manpage等不同格式的文檔：
make pdfdocs
make psdocs
make htmldocs
make mandocs

成為一個(gè)內(nèi)核開發(fā)者
--------------

如果你對Linux內(nèi)核開發(fā)一無所知，你可以看看Linux KernelNewbies項(xiàng)目：
http://kernelnewbies.org
它包含一個(gè)郵件列表，在那里你可以問任何有關(guān)內(nèi)核開發(fā)的基礎(chǔ)問題（在問問題之前先搜索一下存檔，很可能這個(gè)問題已經(jīng)被解答過了。）它還有一個(gè)IRC頻道，你可以在里面實(shí)時(shí)的提問。它還有很多有用的文檔，對于學(xué)習(xí)Linux內(nèi)核開發(fā)很有用。

這個(gè)網(wǎng)站有有關(guān)代碼組織，子系統(tǒng)，當(dāng)前項(xiàng)目（代碼樹之內(nèi)的和之外的）的基本信息。它也描述了一些基本的“物流”信息，比如怎么樣編譯內(nèi)核和怎么樣打補(bǔ)丁。

如果你不知道從何處起步，但是你想找一些任務(wù)來做以加入內(nèi)核開發(fā)社區(qū)，請看一下Linux Kernel Janitor項(xiàng)目：
http://janitor.kernelnewbies.org/
這是一個(gè)很好的起步的地方。它描述了一些相對來說簡單的內(nèi)核中需要清理的和解決的問題。和負(fù)責(zé)這個(gè)項(xiàng)目的開發(fā)者一起工作，你會(huì)學(xué)到如何令你的補(bǔ)丁進(jìn)入Linux內(nèi)核樹的基本知識，而且可能會(huì)為你指明下一步的發(fā)展方向，如果你自己尚不明確的話。

如果你已經(jīng)有了一段代碼想要放到內(nèi)核樹里，但是需要某種形式的幫助，那么kernel-mentors項(xiàng)目就可以幫你的忙了。這是一個(gè)郵件列表，可以在下面找到：
http://selenic.com/mailman/listinfo/kernel-mentors

在你對Linux內(nèi)核代碼作任何實(shí)際的改動(dòng)之前，必須要了解相關(guān)的代碼是如何工作的。為了達(dá)到這個(gè)目的，沒有比直接讀它（很多困難的地方都有很好的注釋）更好的方法了，甚至可能是在某個(gè)特殊工具的幫助下來閱讀。很值得推薦的這樣一種工具是Linux Cross-Reference項(xiàng)目，它可以把源代碼以一種自我引用的、索引的網(wǎng)頁形式顯示出來。一個(gè)非常好的最新的內(nèi)核代碼倉庫可以在這里找到：
http://sosdg.org/~coywolf/lxr

開發(fā)流程
------

Linux內(nèi)核開發(fā)流程當(dāng)前包括一些主內(nèi)核分支，和很多不同的子系統(tǒng)專有的內(nèi)核分支。它們是：
－ 主 2.6.x 內(nèi)核樹
－ 2.6.x.y -stable 內(nèi)核樹
－ 2.6.x -git 內(nèi)核補(bǔ)丁
－ 2.6.x -mm 內(nèi)核補(bǔ)丁
－ 子系統(tǒng)專有內(nèi)核樹和補(bǔ)丁

2.6.x 內(nèi)核樹
-----------
2.6.x 內(nèi)核樹是有Linus Torvalds維護(hù)的，可以在kernel.org的pub/linux/kernel/v2.6目錄里找到。它的開發(fā)流程是這樣的：
－當(dāng)一個(gè)新的內(nèi)核發(fā)布之后，一個(gè)為期兩個(gè)星期的窗口打開，在這段時(shí)間里維護(hù)者可以提交大的補(bǔ)丁給Linus，通常是已經(jīng)在-mm內(nèi)核中存在了一定時(shí)間的補(bǔ)丁。推薦的提交補(bǔ)丁的方式是通過git（有關(guān)git的更多信息可以在http://git.or.cz/找到），但是普通的補(bǔ)丁也是可以的
－兩個(gè)星期之后一個(gè)-rc1內(nèi)核發(fā)布，然后現(xiàn)在只可以再加入不會(huì)為內(nèi)核添加新功能的補(bǔ)丁，因?yàn)槟菢拥难a(bǔ)丁可能會(huì)影響這個(gè)內(nèi)核的穩(wěn)定性。請注意這個(gè)時(shí)候一個(gè)整的新驅(qū)動(dòng)（或者文件系統(tǒng)）可以被接受。因?yàn)橹灰�這個(gè)變動(dòng)是自成一體的并且不影響它之外的代碼的話，就不會(huì)有產(chǎn)生回歸的危險(xiǎn)。在-rc1發(fā)布之后，git可以用來發(fā)送補(bǔ)丁給Linus，但是這些補(bǔ)丁也需要發(fā)到一個(gè)公開的郵件列表里以備審查。
－ 當(dāng)Linus確信當(dāng)前的git（內(nèi)核代碼管理工具）樹已經(jīng)處于一個(gè)合理的健全狀態(tài)，足夠測試時(shí)，一個(gè)新的-rc就會(huì)發(fā)布了。目標(biāo)是每周發(fā)布一個(gè)新的-rc內(nèi)核。
－ 這個(gè)過程將會(huì)持續(xù)到內(nèi)核被認(rèn)為可以發(fā)布為止，整個(gè)流程會(huì)持續(xù)大概6個(gè)星期。

Andrew Morton在linux-kernel郵件列表里寫的有關(guān)內(nèi)核發(fā)布的一句話值得提一下：
“沒有人知道什么時(shí)候一個(gè)內(nèi)核會(huì)發(fā)布，因?yàn)樗�發(fā)布的依據(jù)已經(jīng)掌握的bug狀態(tài)，而不是事先設(shè)想好的一個(gè)時(shí)間線。“

2.6.x.y -stable 內(nèi)核樹
---------------------

有四個(gè)數(shù)字版本號的內(nèi)核是-stable內(nèi)核。他們包含一些相對較小的和重要的修正。這些修正針對的是在一個(gè)給定2.6.x內(nèi)核中發(fā)現(xiàn)的安全問題或者重大的回歸。

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

如果沒有2.6.x.y版本，那么最高版本號的2.6.x內(nèi)核是當(dāng)前穩(wěn)定內(nèi)核。

2.6.x.y由“stable”團(tuán)隊(duì)<stable@kernel.org>維護(hù)，每周發(fā)布一次。

內(nèi)核樹里的文件Documentation/stable_kernel_rules.txt描述了什么樣的改動(dòng)可以被-stable樹所接受，以及發(fā)布流程是怎樣工作的。

2.6.x -git 補(bǔ)丁
--------------
這些是在git倉庫里管理的Linus內(nèi)核樹的每日快照。這些補(bǔ)丁每天發(fā)布一次，代表Linus樹的當(dāng)前狀態(tài)。它們比-rc內(nèi)核更具實(shí)驗(yàn)性質(zhì)，因?yàn)樗鼈兪亲詣?dòng)生成的，以至沒有人曾經(jīng)瞟上一眼來檢查它們是否處于健全狀態(tài)。

2.6.x -mm 內(nèi)核補(bǔ)丁
----------------
這些是Andrew Morton發(fā)布的實(shí)驗(yàn)性質(zhì)的內(nèi)核補(bǔ)丁。Andrew取得所有不同子系統(tǒng)的內(nèi)核樹和補(bǔ)丁，連同從linux-kernel郵件列表里拉過來的補(bǔ)丁，把它們?nèi)诤显谝黄稹＿@個(gè)樹是新功能和補(bǔ)丁證明自己的場所。如果一個(gè)補(bǔ)丁在-mm里證實(shí)了自己的價(jià)值，Andrew或者子系統(tǒng)維護(hù)者就會(huì)把它提交給Linus，以求被收錄于主線內(nèi)核中。

強(qiáng)烈建議所有的新補(bǔ)丁在發(fā)送給Linus之前都先發(fā)到-mm樹里測試一下。

打了此種補(bǔ)丁的內(nèi)核不適用于追求穩(wěn)定的系統(tǒng)中，運(yùn)行它們比運(yùn)行其他任何分支都更具冒險(xiǎn)性。

如果你想幫助內(nèi)核開發(fā)流程，請測試并使用這些內(nèi)核發(fā)布，并在linux-kernel郵件列表里提供回饋，如果你發(fā)現(xiàn)任何問題的話，哪怕什么問題也沒有。

在所有其他實(shí)驗(yàn)性質(zhì)的補(bǔ)丁之外，這些內(nèi)核補(bǔ)丁通常還會(huì)包含在發(fā)布時(shí)在主線-git內(nèi)核中已經(jīng)包含的改動(dòng)。

-mm內(nèi)核沒有一個(gè)固定的發(fā)布計(jì)劃，但是通常在每兩個(gè)-rc內(nèi)核發(fā)布間歇期會(huì)發(fā)布一些-mm內(nèi)核（1到3個(gè)都很常見）。

子系統(tǒng)專有內(nèi)核樹和補(bǔ)丁
-----------------
一些不同的內(nèi)核子系統(tǒng)開發(fā)者公布他們的開發(fā)樹，這樣其他人可以看到在內(nèi)核的不同領(lǐng)域里正在發(fā)生什么。這些樹都會(huì)被包含在-mm內(nèi)核發(fā)布中。

下面是一些不同的內(nèi)核樹的列表：
git樹：
- Kbuild 開發(fā)樹, Sam Ravnborg <sam@ravnborg.org>
kernel.org:/pub/scm/linux/kernel/git/sam/kbuild.git

- ACPI 開發(fā)樹, Len Brown <len.brown@intel.com>
kernel.org:/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6.git

- 塊設(shè)備開發(fā)樹, Jens Axboe <axboe@suse.de>
kernel.org:/pub/scm/linux/kernel/git/axboe/linux-2.6-block.git

- DRM 開發(fā)樹, Dave Airlie <airlied@linux.ie>
kernel.org:/pub/scm/linux/kernel/git/airlied/drm-2.6.git

- ia64 開發(fā)樹, Tony Luck <tony.luck@intel.com>
kernel.org:/pub/scm/linux/kernel/git/aegl/linux-2.6.git

- ieee1394 開發(fā)樹, Jody McIntyre <scjody@modernduck.com>
kernel.org:/pub/scm/linux/kernel/git/scjody/ieee1394.git

- infiniband, Roland Dreier <rolandd@cisco.com>
kernel.org:/pub/scm/linux/kernel/git/roland/infiniband.git

- libata, Jeff Garzik <jgarzik@pobox.com>
kernel.org:/pub/scm/linux/kernel/git/jgarzik/libata-dev.git

- 網(wǎng)絡(luò)驅(qū)動(dòng), Jeff Garzik <jgarzik@pobox.com>
kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git

- pcmcia, Dominik Brodowski <linux@dominikbrodowski.net>
kernel.org:/pub/scm/linux/kernel/git/brodo/pcmcia-2.6.git

- SCSI, James Bottomley <James.Bottomley@SteelEye.com>
kernel.org:/pub/scm/linux/kernel/git/jejb/scsi-misc-2.6.git

其他git內(nèi)核樹可以在http://kernel.org/git找到

quilt trees:
- USB, PCI, Driver Core, and I2C, Greg Kroah-Hartman <gregkh@suse.de>
kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/

報(bào)告Bug
------

bugzilla.kernel.org是Linux內(nèi)核開發(fā)者追蹤內(nèi)核bug的地方。我們鼓勵(lì)用戶在這個(gè)工具中報(bào)告他們發(fā)現(xiàn)的所有bug。欲知使用內(nèi)核bugzilla的具體細(xì)節(jié)，請看：
http://test.kernel.org/bugzilla/faq.html

主內(nèi)核源碼目錄中的REPORTING-BUGS文件有一個(gè)報(bào)告可能有的內(nèi)核bug的模板，并詳細(xì)講述了內(nèi)核開發(fā)者需要什么樣的信息，以便他們可追蹤到問題所在。

郵件列表
------

就像上面的一些文檔所描述的，大多數(shù)核心內(nèi)核開發(fā)者參與Linux內(nèi)核郵件列表的討論。如何訂閱和取消訂閱這個(gè)列表的細(xì)節(jié)可以從這里找到：
http://vger.kernel.org/vger-lists.html#linux-kernel
網(wǎng)上很多地方都有這個(gè)郵件列表的存檔。使用一個(gè)搜索引擎來搜索這些存檔。比如：
http://dir.gmane.org/gmane.linux.kernel
強(qiáng)烈建議你在向列表發(fā)郵件詢問之前，先在存檔中搜索一下你想問的話題。很多事情都已經(jīng)詳細(xì)的討論過了，它們只在郵件列表存檔中有記錄。

很多內(nèi)核子系統(tǒng)也有它們單獨(dú)的郵件列表，在那里開發(fā)者們做他們的開發(fā)工作。請查看MAINTAINER文件來找到這些不同子系統(tǒng)的郵件列表。

很多郵件列表放置于kernel.org之上。有關(guān)它們的信息可以在這里找到：
http://vger.kernel.org/vger-lists.html

請記住在使用這些列表時(shí)請遵守良好的行為習(xí)慣。下面的URL有一些如何在郵件列表上與人交流的簡單的準(zhǔn)則，雖然有一點(diǎn)俗氣：
http://www.albion.com/netiquette

如果有許多人回復(fù)你的郵件，收件人的抄送列表會(huì)變得很長。在沒有一個(gè)合理的理由時(shí)不要把任何人從抄送列表中去掉，或者不要只回復(fù)被列出的地址。要對于收到同一封信兩次感到習(xí)慣，一次從發(fā)信者，一次從郵件列表。不要為了好看而加上別致的郵件頭部，人們不喜歡這樣。

記得保證你的回復(fù)的上下文和屬性的完整性，在你的回復(fù)的最上方保留類似“John Kernelhacker wrote ...“的字樣，把你的回復(fù)寫在被引用的段落之間，而不要寫在郵件的最上方。

如果你在你的郵件里加入了補(bǔ)丁，要確保它們是純文本，就想Documentation/SubmittingPatches里所說的。內(nèi)核開發(fā)者不希望處理附件或者壓縮的補(bǔ)�。凰麄儠�(huì)希望評價(jià)你的補(bǔ)丁的每一行，只有純文本才符合這個(gè)要求。確保你使用的郵件客戶端軟件不會(huì)破壞空格和制表符。你可以發(fā)一個(gè)郵件給你自己，然后應(yīng)用你自己的補(bǔ)丁來先做個(gè)測試。如果不行，修復(fù)你的郵件程序或者換一個(gè)。

最重要的一點(diǎn)，請記得顯示出你對其他訂閱者的尊重。

和社區(qū)一起工作
-----------

內(nèi)核社區(qū)的目標(biāo)是提供可能提供的最好的內(nèi)核。當(dāng)你提交了一個(gè)補(bǔ)丁等待被收錄時(shí)，它會(huì)被且僅被該領(lǐng)域的技術(shù)權(quán)威所檢查。所以，你應(yīng)該期待什么呢？
－ 批評
－ 評論
－ 被要求改動(dòng)
－ 被要求解釋
－ 沉默

記住，這是讓你的補(bǔ)丁進(jìn)入內(nèi)核的一部分。你必須能夠接受對你的補(bǔ)丁的批評和評論，在技術(shù)的層面上評估它，然后要么對你的補(bǔ)丁作出修改，要么提供清晰而言簡意賅的理由解釋為什么不應(yīng)該做改動(dòng)。如果沒有對你的補(bǔ)丁的回復(fù)，等幾天再試一次，有時(shí)候在流量很大的時(shí)候信件可能丟失，或被人忽略遺忘了。

你不應(yīng)該做什么：
－ 期待你的補(bǔ)丁沒有任何疑問的被接受
－ 不接受批評，不承認(rèn)缺點(diǎn)
－ 忽略評論
－ 在不做任何修改的情況下再次提交補(bǔ)丁

在一個(gè)尋找可能存在的最好的技術(shù)解決方案的社區(qū)里，關(guān)于一個(gè)補(bǔ)丁怎樣的有用必定會(huì)存在不同的意見。你應(yīng)該采取合作的態(tài)度，愿意改變你的意見以適應(yīng)內(nèi)核的需要�；蛘咧辽僭敢庾C明的你的觀點(diǎn)有價(jià)值。記住，犯錯(cuò)誤是可以接受的，只要你愿意朝著正確的解決方案努力。

如果對于你的第一個(gè)補(bǔ)丁的回應(yīng)只是一些要求你改正的意見，這很正常。這并不意味著你的補(bǔ)丁將不會(huì)被接受，這些意見也不是針對你本人的。你要做的只是改正你的補(bǔ)丁然后重新發(fā)送。

內(nèi)核社區(qū)和企業(yè)架構(gòu)的區(qū)別
-------------------

內(nèi)核社區(qū)和大多數(shù)傳統(tǒng)的企業(yè)開發(fā)環(huán)境工作形式不一樣。這里有一個(gè)列表你可以嘗試遵照執(zhí)行以避免出現(xiàn)問題：
關(guān)于你提交的補(bǔ)丁的好的說法：
－ “這個(gè)可以解決多個(gè)問題。”
－ “這個(gè)刪除了2000行代碼�！�
－ “這個(gè)補(bǔ)丁解釋了我嘗試想描述的東西�！�
－ “我在5個(gè)不同的架構(gòu)上測試了它……”
－ “這里是一系列的小補(bǔ)丁，它們可以……”
－ “這個(gè)在典型的機(jī)器上可以提高表現(xiàn)……”

你應(yīng)該避免的壞的說法：
－ “我們在AIX/ptx/Solaris上都是這樣做的，所以它一定是好的……”
－ “我已經(jīng)這樣做20年了，所以……”
－ “我的公司需要這樣做來掙錢”
－ “這是我的一千頁的設(shè)計(jì)文檔，它解釋了我的想法”
－ “我已經(jīng)在它上面花了6個(gè)月的心血……”
－ “這里是一個(gè)5000行的補(bǔ)丁，它……”
－ “我重新寫了所有現(xiàn)有的垃圾，在這里……”
－ “我有完成期限，這個(gè)補(bǔ)丁必須現(xiàn)在被應(yīng)用。”

內(nèi)核社區(qū)和大多數(shù)傳統(tǒng)軟件工程工作環(huán)境的另一個(gè)不同是沒有面對面的交流。使用email和irc作為主要交流形式的好處之一是不會(huì)存在基于性別或者種族的歧視。Linux內(nèi)核工作環(huán)境接受女士和少數(shù)民族，因?yàn)槟愕拇嬖谥皇且粋�(gè)email地址。國際化也幫助我們實(shí)現(xiàn)了平等的工作環(huán)境，因?yàn)槟銦o法根據(jù)一個(gè)人的名字來判斷一個(gè)人的性別。一個(gè)男人可以叫Andrea，一個(gè)女人可以叫Pat。大多數(shù)為Linux內(nèi)核做過工作或者發(fā)表過觀點(diǎn)的女性對此都深有體會(huì)。

對于不習(xí)慣英語的人來說語言障礙可能會(huì)導(dǎo)致一些問題。對于語言的良好的掌握可以令思想在郵件列表上交流的更暢通，所以建議你在發(fā)送郵件之前檢查一下你的郵件內(nèi)容在英語里是否有意義。

打散你的補(bǔ)丁
---------

Linux內(nèi)核社區(qū)不樂意接受大段的代碼，一般會(huì)在收到時(shí)立刻丟棄。你的補(bǔ)丁需要適當(dāng)?shù)谋唤榻B，討論，并打散為細(xì)小的，獨(dú)立的片段。這幾乎和公司里經(jīng)常做的完全背道而馳。你的提議必須在開發(fā)流程的早期提出，這樣你才可以收到足夠的關(guān)于你的工作的回饋。這也會(huì)令社區(qū)感覺到你是在和他們一起工作，而不是利用他們作為傾倒你的補(bǔ)丁的場所。但是，請不要一次向郵件列表發(fā)送超過50封email，你的一系列補(bǔ)丁的個(gè)數(shù)應(yīng)該永遠(yuǎn)小于這個(gè)數(shù)字。

把補(bǔ)丁打散的理由如下：

1) 小的補(bǔ)丁增加了你的補(bǔ)丁被應(yīng)用的機(jī)會(huì)，因?yàn)樗�不需要花太多的時(shí)間和精力來檢查它的正確性。一個(gè)5行的補(bǔ)丁，一個(gè)維護(hù)者只要花一秒鐘瞟一眼然后就可以應(yīng)用了。不過，一個(gè)500行的補(bǔ)丁需要一個(gè)小時(shí)來檢查是否有錯(cuò)誤（所需的時(shí)間跟補(bǔ)丁的大小差不多成指數(shù)級別增長）。

小補(bǔ)丁也使得在出錯(cuò)的時(shí)候很容易debug。如果出了問題，小補(bǔ)丁可以一個(gè)一個(gè)的取消，大補(bǔ)丁就比較麻煩了。
2) 除了要把補(bǔ)丁打散之外，在提交之前還要重寫和簡化（或者只是簡單的重排序）你的補(bǔ)丁。這一點(diǎn)也是很重要的。

這里有一個(gè)內(nèi)核開發(fā)者Al Viro所做的類比：
“想一下一個(gè)老師為一個(gè)數(shù)學(xué)系學(xué)生批改作業(yè)的情景。老師不希望看到學(xué)生在回答出正確答案之前的嘗試和失敗。他們想看到最清楚的，最優(yōu)美的答案。一個(gè)好學(xué)生了解這一點(diǎn)，并不會(huì)在得到最終答案之前把他們的中間結(jié)果提交上去。

對于內(nèi)核開發(fā)來說同樣是這樣。維護(hù)者和評論者不希望看到問題的解決方案背后的思考過程。他們想看到一個(gè)簡單和優(yōu)美的解決方案。”

提供一個(gè)優(yōu)美的解決方案和同社區(qū)一起工作討論你未完成的作品，要維持此二者之間的平衡可能是一個(gè)很有挑戰(zhàn)性的事情。所以應(yīng)及早的參與一個(gè)開發(fā)流程以獲得回饋來改進(jìn)你的作品，但仍要保證你的補(bǔ)丁的小塊頭，這樣它們可能提早被接受，哪怕是在你的整個(gè)作品還為完成時(shí)。

也請注意，如果你的補(bǔ)丁尚未完成而且還需要修改，請不要提交。

證明你的改動(dòng)
---------

除了打散你的補(bǔ)丁之外，讓Linux社區(qū)理解為什么他們要加入這項(xiàng)改動(dòng)也是很重要的。新的功能必須要被證實(shí)它們需要而且有用。

為你的改動(dòng)寫文檔
-------------

在你提交補(bǔ)丁時(shí)，要格外留心你在email里說的話。這些信息將會(huì)成為這個(gè)補(bǔ)丁的ChangeLog信息，將會(huì)被保留從而使每個(gè)人任何時(shí)候都可以看到。它必須完整的描述這個(gè)補(bǔ)丁，包括：
－ 為什么這個(gè)改動(dòng)是需要的
－ 這個(gè)補(bǔ)丁的整體設(shè)計(jì)方案
－ 實(shí)現(xiàn)細(xì)節(jié)
－ 測試結(jié)果

欲知這個(gè)過程到底看起來是什么樣子的，請看這個(gè)文檔的ChangeLog部分：
“The Perfect Patch”
http://www.zip.com.au/~akpm/linux/patches/stuff/tpp.txt




所有這些事情有時(shí)候很難做到。要想完美做到這些要求可能需要幾年的時(shí)間。這是一個(gè)持續(xù)的發(fā)展過程，需要很多耐心和決心。但是不要放棄，這是可以實(shí)現(xiàn)的。很多人已經(jīng)做到了這一點(diǎn)，每個(gè)人都經(jīng)歷過你現(xiàn)在這個(gè)階段。



-------------
感謝Paolo Ciarrocchi允許我在他所寫的文章的基礎(chǔ)上寫成本文的“開發(fā)流程”部分，感謝Randy Dunlap和Gerrit Huizenga為了他們應(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, Frans Pop,David A. Wheeler, Junio Hamano, Michael Kerrisk, 和 Alex Shepard為了他們對于本文初稿的評論和意見。



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

[ 本帖最后由 leviathan.alan 于 2006-6-20 09:51 編輯 ]