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)該不會再有大的改動了，如果有本文會隨時更新
時間倉促，恐難免錯漏，歡迎指正
原文：http://permalink.gmane.org/gmane.linux.kernel/349656 (轉(zhuǎn)貼說明：也可以在內(nèi)核源代碼目錄下的Documentation/HOWTO找到本文英文版)
譯文：

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

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

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

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

介紹
---

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

內(nèi)核幾乎全是用C寫成的，有一些架構(gòu)相關(guān)的部分是用匯編語言寫成的。熟練掌握C語言是內(nèi)核開發(fā)的必備條件。匯編語言（任何架構(gòu)）的了解不是必須的，除非你準(zhǔn)備做某個架構(gòu)的底層開發(fā)。雖然下面這些書不能完全代替扎實的C語言教學(xué)和/或者成年累月的經(jīng)驗，他們還是不錯的參考，如果用得著的話：
- "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類型除法和浮點數(shù)是不被允許的。有時候會很難理解內(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)過時間檢驗的。他們發(fā)現(xiàn)遵循這些標(biāo)準(zhǔn)對于這樣一個大規(guī)模的且地理上分散的團(tuán)隊是最佳的選擇。嘗試提前學(xué)習(xí)盡可能多的有關(guān)這些標(biāo)準(zhǔn)的知識，因為它們都有很好的文檔；不要期望別人會遵照你或者你公司的行事方式。

法律問題
------

Linux內(nèi)核源代碼依照GPL發(fā)布。請參考源代碼樹下的COPYING文件，以獲取有關(guān)這個許可證的詳細(xì)信息。如果你對這個許可證有疑問，請聯(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ū)交流來說有不可估量的價值。當(dāng)新的功能加進(jìn)內(nèi)核的時候，通常建議作者把解釋這個新功能的文檔也加進(jìn)內(nèi)核。如果一個內(nèi)核變動導(dǎo)致了內(nèi)核對用戶空間界面的改變，建議你把這個信息或者一個解釋了這個變動的manpage的補(bǔ)丁發(fā)送給手冊頁的維護(hù)者 mtk-manpages@gmx.net。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

在你對Linux內(nèi)核代碼作任何實際的改動之前，必須要了解相關(guān)的代碼是如何工作的。為了達(dá)到這個目的，沒有比直接讀它（很多困難的地方都有很好的注釋）更好的方法了，甚至可能是在某個特殊工具的幫助下來閱讀。很值得推薦的這樣一種工具是Linux Cross-Reference項目，它可以把源代碼以一種自我引用的、索引的網(wǎng)頁形式顯示出來。一個非常好的最新的內(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)一個新的內(nèi)核發(fā)布之后，一個為期兩個星期的窗口打開，在這段時間里維護(hù)者可以提交大的補(bǔ)丁給Linus，通常是已經(jīng)在-mm內(nèi)核中存在了一定時間的補(bǔ)丁。推薦的提交補(bǔ)丁的方式是通過git（有關(guān)git的更多信息可以在http://git.or.cz/找到），但是普通的補(bǔ)丁也是可以的
－兩個星期之后一個-rc1內(nèi)核發(fā)布，然后現(xiàn)在只可以再加入不會為內(nèi)核添加新功能的補(bǔ)丁，因為那樣的補(bǔ)丁可能會影響這個內(nèi)核的穩(wěn)定性。請注意這個時候一個整的新驅(qū)動（或者文件系統(tǒng)）可以被接受。因為只要這個變動是自成一體的并且不影響它之外的代碼的話，就不會有產(chǎn)生回歸的危險。在-rc1發(fā)布之后，git可以用來發(fā)送補(bǔ)丁給Linus，但是這些補(bǔ)丁也需要發(fā)到一個公開的郵件列表里以備審查。
－ 當(dāng)Linus確信當(dāng)前的git（內(nèi)核代碼管理工具）樹已經(jīng)處于一個合理的健全狀態(tài)，足夠測試時，一個新的-rc就會發(fā)布了。目標(biāo)是每周發(fā)布一個新的-rc內(nèi)核。
－ 這個過程將會持續(xù)到內(nèi)核被認(rèn)為可以發(fā)布為止，整個流程會持續(xù)大概6個星期。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

報告Bug
------

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

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

郵件列表
------

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

證明你的改動
---------

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

為你的改動寫文檔
-------------

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

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




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



-------------
感謝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 編輯 ]