如何成為一個(gè)Linux內(nèi)核開(kāi)發(fā)者

作者: 出處:51CTO論壇　 ( 1 ) 磚  ( 2 ) 好  評(píng)論 ( 0 ) 條 　進(jìn)入論壇

更新時(shí)間：2006-08-29 08:56
關(guān) 鍵 詞：Linux
閱讀提示：本文將教你如何成為一個(gè)Linux內(nèi)核開(kāi)發(fā)者以及學(xué)會(huì)如何和Linux內(nèi)核社區(qū)一起工作。它不包含任何有關(guān)內(nèi)核編程的技術(shù)細(xì)節(jié)，但是會(huì)幫你在這方面指明方向。

你想成知道如何成為一個(gè)Linux內(nèi)核開(kāi)發(fā)者么？或者你的老板告訴你，“去為這個(gè)設(shè)備寫一個(gè)Linux驅(qū)動(dòng)。“這篇文檔的目的，就是通過(guò)描述你需要經(jīng)歷的過(guò)程和提示你如何和社區(qū)一起工作，來(lái)教給你為達(dá)到這些目的所需要知道的所有知識(shí)。本文也嘗試解釋社區(qū)為什么這樣工作的一些原因。
內(nèi)核幾乎全是用C寫成的，有一些架構(gòu)相關(guān)的部分是用匯編語(yǔ)言寫成的。熟練掌握C語(yǔ)言是內(nèi)核開(kāi)發(fā)的必備條件。匯編語(yǔ)言（任何架構(gòu)）的了解不是必須的，除非你準(zhǔn)備做某個(gè)架構(gòu)的底層開(kāi)發(fā)。雖然下面這些書不能完全代替扎實(shí)的C語(yǔ)言教學(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)中沒(méi)有的擴(kuò)展。內(nèi)核是自成體系的 C 環(huán)境，它并不依賴標(biāo)準(zhǔn)C庫(kù)，所以某些C語(yǔ)言標(biāo)準(zhǔn)是不支持的。任意長(zhǎng)度long long類型除法和浮點(diǎn)數(shù)是不被允許的。有時(shí)候會(huì)很難理解內(nèi)核對(duì)于它所使用的工具鏈和擴(kuò)展的假定，而且不幸的是也沒(méi)有關(guān)于它們的絕對(duì)的參考。請(qǐng)查閱gcc 的info頁(yè)(`info gcc`)以獲取有關(guān)信息。
請(qǐng)記住你是在嘗試學(xué)習(xí)如何與已經(jīng)存在的開(kāi)發(fā)社區(qū)一起工作。這是一群成分復(fù)雜的人們，他們對(duì)于代碼，風(fēng)格和步驟有高的標(biāo)準(zhǔn)。這些標(biāo)準(zhǔn)是經(jīng)過(guò)時(shí)間檢驗(yàn)的。
他們發(fā)現(xiàn)遵循這些標(biāo)準(zhǔn)對(duì)于這樣一個(gè)大規(guī)模的且地理上分散的團(tuán)隊(duì)是最佳的選擇。嘗試提前學(xué)習(xí)盡可能多的有關(guān)這些標(biāo)準(zhǔn)的知識(shí)，因?yàn)樗鼈兌加泻芎玫奈臋n；不要期望別人會(huì)遵照你或者你公司的行事方式。
法律問(wèn)題
Linux內(nèi)核源代碼依照GPL發(fā)布。請(qǐng)參考源代碼樹(shù)下的COPYING文件，以獲取有關(guān)這個(gè)許可證的詳細(xì)信息。如果你對(duì)這個(gè)許可證有疑問(wèn)，請(qǐng)聯(lián)系你的律師，不要在Linux內(nèi)核郵件列表里詢問(wèn)。郵件列表里的人們不是律師，你不應(yīng)該依賴于他們對(duì)于法律問(wèn)題的解釋。
欲了解有關(guān)GPL的常見(jiàn)問(wèn)題和答案，請(qǐng)看：
http://www./licenses/gpl-faq.html
文檔
Linux內(nèi)核源代碼樹(shù)有很多文檔，它們對(duì)于學(xué)習(xí)如何與內(nèi)核社區(qū)交流來(lái)說(shuō)有不可估量的價(jià)值。當(dāng)新的功能加進(jìn)內(nèi)核的時(shí)候，通常建議作者把解釋這個(gè)新功能的文檔也加進(jìn)內(nèi)核。如果一個(gè)內(nèi)核變動(dòng)導(dǎo)致了內(nèi)核對(duì)用戶空間界面的改變，建議你把這個(gè)信息或者一個(gè)解釋了這個(gè)變動(dòng)的manpage的補(bǔ)丁發(fā)送給手冊(cè)頁(yè)的維護(hù)者 mtk-manpages@gmx.net。
這里有一個(gè)內(nèi)核源代碼樹(shù)里需要閱讀的文件列表：
README
這個(gè)文件簡(jiǎn)單介紹了Linux內(nèi)核的背景，并描述了配置和編譯內(nèi)核需要做哪些事情。內(nèi)核新手應(yīng)該從這里開(kāi)始。
Do*****entation/Changes
這個(gè)文件介紹了成功編譯和運(yùn)行內(nèi)核所需要各種不同軟件的列表。
Do*****entation/CodingStyle
這個(gè)文件描述了Linux內(nèi)核代碼風(fēng)格，還有背后的一些原因。所有的新代碼的要符合這個(gè)文檔里的準(zhǔn)則。大多數(shù)維護(hù)者只會(huì)接受符合這些規(guī)則的補(bǔ)丁，很多人只看符合正確風(fēng)格的代碼。
Do*****entation/SubmittingPatches
Do*****entation/SubmittingDrivers
這些文件非常詳細(xì)的介紹了如何成功的創(chuàng)建和發(fā)送一個(gè)補(bǔ)丁，包括（但不限于）：
－Email內(nèi)容
－Email格式
－發(fā)送給誰(shuí)
遵守所有這些規(guī)則并不能保證成功（對(duì)所有的補(bǔ)丁都需要進(jìn)行內(nèi)容和風(fēng)格的詳細(xì)檢查），但是不遵守這些規(guī)則就一定不會(huì)成功。
其他關(guān)于如何創(chuàng)建補(bǔ)丁的很好的文章有：
“The Perfect Patch"
http://www./~akpm/linux/patches/stuff/tpp.txt
"Linux kernle patch submission format"
http://linux./patch-format.html
Do*****entation/stable_api_nonsense.txt
這個(gè)文件解釋了有意識(shí)的決定－不在內(nèi)核里使用穩(wěn)定的API－的原因，包括：
－子系統(tǒng)分隔層（為了兼容？）
－操作系統(tǒng)之間的驅(qū)動(dòng)可移植性
－緩和（或者阻止）內(nèi)核源代碼樹(shù)的急速變動(dòng)
這個(gè)文檔對(duì)于了解Linux的開(kāi)發(fā)哲學(xué)是非常關(guān)鍵的，對(duì)于由開(kāi)發(fā)其他操作系統(tǒng)轉(zhuǎn)而開(kāi)發(fā)Linux人也是很重要的。
Do*****entation/SecurityBugs
如果你感覺(jué)到你發(fā)現(xiàn)了Linux內(nèi)核里的一個(gè)安全問(wèn)題，請(qǐng)遵照這個(gè)文檔里所描述的步驟來(lái)提醒內(nèi)核開(kāi)發(fā)者，并幫助解決問(wèn)題。
Do*****entation/ManagementStyle
這個(gè)文檔描述了Linux內(nèi)核維護(hù)者如何運(yùn)作，以及他們?yōu)槭裁催@樣做。它對(duì)于任何內(nèi)核開(kāi)發(fā)新手（或者任何對(duì)本話題感興趣的人）來(lái)說(shuō)是非常重要的。
因?yàn)樗忉屃艘恍T有的錯(cuò)誤概念，可解決有關(guān)內(nèi)核維護(hù)者獨(dú)特行為的疑惑。
Do*****entation/stable_kernel_rules.txt
本文件描述了穩(wěn)定版本內(nèi)核釋出的規(guī)則，還有如果你想對(duì)其中的一個(gè)版本做一些改動(dòng)應(yīng)該做些什么。
Do*****entation/kernel-docs.txt
一個(gè)有關(guān)內(nèi)核開(kāi)發(fā)的外部文檔的列表。如果你在內(nèi)核內(nèi)部文檔里沒(méi)有找到? 要找的東西，你可以參考這個(gè)列表。
Do*****entation/applying-patches.txt
介紹了對(duì)于什么是補(bǔ)丁，以及如何應(yīng)用補(bǔ)丁于不同的內(nèi)核開(kāi)發(fā)分支。
內(nèi)核也有很多可以從源代碼自動(dòng)產(chǎn)生的文檔。這包括內(nèi)核內(nèi)部API的全面描述，有關(guān)如何處理好鎖定的規(guī)則。這些文檔會(huì)被創(chuàng)建于 Do*****entation/DocBook/文件夾中。在內(nèi)核主源碼樹(shù)中通過(guò)運(yùn)行下面的命令可以創(chuàng)建出PDF，Postscript， HTML和manpage等不同格式的文檔：

make pdfdocs make psdocs make htmldocs make mandocs

成為一個(gè)內(nèi)核開(kāi)發(fā)者
如果你對(duì)Linux內(nèi)核開(kāi)發(fā)一無(wú)所知，你可以看看Linux KernelNewbies項(xiàng)目：
http://
它包含一個(gè)郵件列表，在那里你可以問(wèn)任何有關(guān)內(nèi)核開(kāi)發(fā)的基礎(chǔ)問(wèn)題（在問(wèn)問(wèn)題之前先搜索一下存檔，很可能這個(gè)問(wèn)題已經(jīng)被解答過(guò)了。）它還有一個(gè)IRC頻道，你可以在里面實(shí)時(shí)的提問(wèn)。它還有很多有用的文檔，對(duì)于學(xué)習(xí)Linux內(nèi)核開(kāi)發(fā)很有用。
這個(gè)網(wǎng)站有有關(guān)代碼組織，子系統(tǒng)，當(dāng)前項(xiàng)目（代碼樹(shù)之內(nèi)的和之外的）的基本信息。它也描述了一些基本的“物流”信息，比如怎么樣編譯內(nèi)核和怎么樣打補(bǔ)丁。
如果你不知道從何處起步，但是你想找一些任務(wù)來(lái)做以加入內(nèi)核開(kāi)發(fā)社區(qū)，請(qǐng)看一下Linux Kernel Janitor項(xiàng)目：
http://janitor./
這是一個(gè)很好的起步的地方。它描述了一些相對(duì)來(lái)說(shuō)簡(jiǎn)單的內(nèi)核中需要清理的和解決的問(wèn)題。和負(fù)責(zé)這個(gè)項(xiàng)目的開(kāi)發(fā)者一起工作，你會(huì)學(xué)到如何令你的補(bǔ)丁進(jìn)入Linux內(nèi)核樹(shù)的基本知識(shí)，而且可能會(huì)為你指明下一步的發(fā)展方向，如果你自己尚不明確的話。
如果你已經(jīng)有了一段代碼想要放到內(nèi)核樹(shù)里，但是需要某種形式的幫助，那么kernel-mentors項(xiàng)目就可以幫你的忙了。這是一個(gè)郵件列表，可以在下面找到：
http:///mailman/listinfo/kernel-mentors
在你對(duì)Linux內(nèi)核代碼作任何實(shí)際的改動(dòng)之前，必須要了解相關(guān)的代碼是如何工作的。為了達(dá)到這個(gè)目的，沒(méi)有比直接讀它（很多困難的地方都有很好的注釋）更好的方法了，甚至可能是在某個(gè)特殊工具的幫助下來(lái)閱讀。很值得推薦的這樣一種工具是Linux Cross-Reference項(xiàng)目，它可以把源代碼以一種自我引用的、索引的網(wǎng)頁(yè)形式顯示出來(lái)。一個(gè)非常好的最新的內(nèi)核代碼倉(cāng)庫(kù)可以在這里找到： http:///~coywolf/lxr
開(kāi)發(fā)流程
Linux內(nèi)核開(kāi)發(fā)流程當(dāng)前包括一些主內(nèi)核分支，和很多不同的子系統(tǒng)專有的內(nèi)核分支。它們是：

－ 主 2.6.x 內(nèi)核樹(shù) － 2.6.x.y -stable 內(nèi)核樹(shù) － 2.6.x -git 內(nèi)核補(bǔ)丁 － 2.6.x -mm 內(nèi)核補(bǔ)丁 － 子系統(tǒng)專有內(nèi)核樹(shù)和補(bǔ)丁

2.6.x 內(nèi)核樹(shù)
2.6.x 內(nèi)核樹(shù)是有Linus Torvalds維護(hù)的，可以在的pub/linux/kernel/v2.6目錄里找到。它的開(kāi)發(fā)流程是這樣的：
－當(dāng)一個(gè)新的內(nèi)核發(fā)布之后，一個(gè)為期兩個(gè)星期的窗口打開(kāi)，在這段時(shí)間里維護(hù)者可以提交大的補(bǔ)丁給Linus，通常是已經(jīng)在-mm內(nèi)核中存在了一定時(shí)間的補(bǔ)丁。推薦的提交補(bǔ)丁的方式是通過(guò)git（有關(guān)git的更多信息可以在http://git./找到），但是普通的補(bǔ)丁也是可以的－兩個(gè)星期之后一個(gè)-rc1內(nèi)核發(fā)布，然后現(xiàn)在只可以再加入不會(huì)為內(nèi)核添加新功能的補(bǔ)丁，因?yàn)槟菢拥难a(bǔ)丁可能會(huì)影響這個(gè)內(nèi)核的穩(wěn)定性。請(qǐng)注意這個(gè)時(shí)候一個(gè)整的新驅(qū)動(dòng)（或者文件系統(tǒng)）可以被接受。因?yàn)橹灰@個(gè)變動(dòng)是自成一體的并且不影響它之外的代碼的話，就不會(huì)有產(chǎn)生回歸的危險(xiǎn)。在-rc1發(fā)布之后，git可以用來(lái)發(fā)送補(bǔ)丁給Linus，但是這些補(bǔ)丁也需要發(fā)到一個(gè)公開(kāi)的郵件列表里以備審查。
－ 當(dāng)Linus確信當(dāng)前的git（內(nèi)核代碼管理工具）樹(shù)已經(jīng)處于一個(gè)合理的健全狀態(tài)，足夠測(cè)試時(shí)，一個(gè)新的-rc就會(huì)發(fā)布了。目標(biāo)是每周發(fā)布一個(gè)新的-rc內(nèi)核。
－ 這個(gè)過(guò)程將會(huì)持續(xù)到內(nèi)核被認(rèn)為可以發(fā)布為止，整個(gè)流程會(huì)持續(xù)大概6個(gè)星期。
Andrew Morton在linux-kernel郵件列表里寫的有關(guān)內(nèi)核發(fā)布的一句話值得提一下： “沒(méi)有人知道什么時(shí)候一個(gè)內(nèi)核會(huì)發(fā)布，因?yàn)樗l(fā)布的依據(jù)已經(jīng)掌握的bug狀態(tài)，而不是事先設(shè)想好的一個(gè)時(shí)間線。
2.6.x.y -stable 內(nèi)核樹(shù)
有四個(gè)數(shù)字版本號(hào)的內(nèi)核是-stable內(nèi)核。他們包含一些相對(duì)較小的和重要的修正。這些修正針對(duì)的是在一個(gè)給定2.6.x內(nèi)核中發(fā)現(xiàn)的安全問(wèn)題或者重大的回歸。
對(duì)于想使用最新的穩(wěn)定內(nèi)核并且對(duì)于幫助測(cè)試開(kāi)發(fā)/實(shí)驗(yàn)版本不感興趣的用戶，這是推薦使用的版本。
如果沒(méi)有2.6.x.y版本，那么最高版本號(hào)的2.6.x內(nèi)核是當(dāng)前穩(wěn)定內(nèi)核。
2.6.x.y由“stable”團(tuán)隊(duì)維護(hù)，每周發(fā)布一次。
內(nèi)核樹(shù)里的文件Do*****entation/stable_kernel_rules.txt描述了什么樣的改動(dòng)可以被-stable樹(shù)所接受，以及發(fā)布流程是怎樣工作的。
2.6.x -git 補(bǔ)丁
這些是在git倉(cāng)庫(kù)里管理的Linus內(nèi)核樹(shù)的每日快照。這些補(bǔ)丁每天發(fā)布一次，代表Linus樹(shù)的當(dāng)前狀態(tài)。它們比-rc內(nèi)核更具實(shí)驗(yàn)性質(zhì)，因?yàn)樗鼈兪亲詣?dòng)生成的，以至沒(méi)有人曾經(jīng)瞟上一眼來(lái)檢查它們是否處于健全狀態(tài)。
2.6.x -mm 內(nèi)核補(bǔ)丁
　這些是Andrew Morton發(fā)布的實(shí)驗(yàn)性質(zhì)的內(nèi)核補(bǔ)丁。Andrew取得所有不同子系統(tǒng)的內(nèi)核樹(shù)和補(bǔ)丁，連同從linux-kernel郵件列表里拉過(guò)來(lái)的補(bǔ)丁，把它們?nèi)诤显谝黄?。這個(gè)樹(shù)是新功能和補(bǔ)丁證明自己的場(chǎng)所。如果一個(gè)補(bǔ)丁在-mm里證實(shí)了自己的價(jià)值，Andrew或者子系統(tǒng)維護(hù)者就會(huì)把它提交給Linus，以求被收錄于主線內(nèi)核中。
強(qiáng)烈建議所有的新補(bǔ)丁在發(fā)送給Linus之前都先發(fā)到-mm樹(shù)里測(cè)試一下。
打了此種補(bǔ)丁的內(nèi)核不適用于追求穩(wěn)定的系統(tǒng)中，運(yùn)行它們比運(yùn)行其他任何分支都更具冒險(xiǎn)性。
如果你想幫助內(nèi)核開(kāi)發(fā)流程，請(qǐng)測(cè)試并使用這些內(nèi)核發(fā)布，并在linux-kernel郵件列表里提供回饋，如果你發(fā)現(xiàn)任何問(wèn)題的話，哪怕什么問(wèn)題也沒(méi)有。
在所有其他實(shí)驗(yàn)性質(zhì)的補(bǔ)丁之外，這些內(nèi)核補(bǔ)丁通常還會(huì)包含在發(fā)布時(shí)在主線-git內(nèi)核中已經(jīng)包含的改動(dòng)。
-mm內(nèi)核沒(méi)有一個(gè)固定的發(fā)布計(jì)劃，但是通常在每?jī)蓚€(gè)-rc內(nèi)核發(fā)布間歇期會(huì)發(fā)布一些-mm內(nèi)核（1到3個(gè)都很常見(jiàn)）。
子系統(tǒng)專有內(nèi)核樹(shù)和補(bǔ)丁
一些不同的內(nèi)核子系統(tǒng)開(kāi)發(fā)者公布他們的開(kāi)發(fā)樹(shù)，這樣其他人可以看到在內(nèi)核的不同領(lǐng)域里正在發(fā)生什么。這些樹(shù)都會(huì)被包含在-mm內(nèi)核發(fā)布中。
下面是一些不同的內(nèi)核樹(shù)的列表：

git樹(shù)： - Kbuild 開(kāi)發(fā)樹(shù), Sam Ravnborg :/pub/scm/linux/kernel/git/sam/kbuild.git - ACPI 開(kāi)發(fā)樹(shù), Len Brown :/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6.git - 塊設(shè)備開(kāi)發(fā)樹(shù), Jens Axboe :/pub/scm/linux/kernel/git/axboe/linux-2.6-block.git - DRM 開(kāi)發(fā)樹(shù), Dave Airlie :/pub/scm/linux/kernel/git/airlied/drm-2.6.git - ia64 開(kāi)發(fā)樹(shù), Tony Luck :/pub/scm/linux/kernel/git/aegl/linux-2.6.git - ieee1394 開(kāi)發(fā)樹(shù), Jody McIntyre :/pub/scm/linux/kernel/git/scjody/ieee1394.git - infiniband, Roland Dreier :/pub/scm/linux/kernel/git/roland/infiniband.git - libata, Jeff Garzik :/pub/scm/linux/kernel/git/jgarzik/libata-dev.git - 網(wǎng)絡(luò)驅(qū)動(dòng), Jeff Garzik :/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git - pcmcia, Dominik Brodowski :/pub/scm/linux/kernel/git/brodo/pcmcia-2.6.git - SCSI, James Bottomley :/pub/scm/linux/kernel/git/jejb/scsi-misc-2.6.git 其他git內(nèi)核樹(shù)可以在http:///git找到 quilt trees: - USB, PCI, Driver Core, and I2C, Greg Kroah-Hartman /pub/linux/kernel/people/gregkh/gregkh-2.6/

報(bào)告Bug
bugzilla.是Linux內(nèi)核開(kāi)發(fā)者追蹤內(nèi)核bug的地方。我們鼓勵(lì)用戶在這個(gè)工具中報(bào)告他們發(fā)現(xiàn)的所有bug。欲知使用內(nèi)核bugzilla的具體細(xì)節(jié)，請(qǐng)看： http://test./bugzilla/faq.html
主內(nèi)核源碼目錄中的REPORTING-BUGS文件有一個(gè)報(bào)告可能有的內(nèi)核bug的模板，并詳細(xì)講述了內(nèi)核開(kāi)發(fā)者需要什么樣的信息，以便他們可追蹤到問(wèn)題所在。
郵件列表
就像上面的一些文檔所描述的，大多數(shù)核心內(nèi)核開(kāi)發(fā)者參與Linux內(nèi)核郵件列表的討論。如何訂閱和取消訂閱這個(gè)列表的細(xì)節(jié)可以從這里找到：
http://vger./vger-lists.html#linux-kernel
網(wǎng)上很多地方都有這個(gè)郵件列表的存檔。使用一個(gè)搜索引擎來(lái)搜索這些存檔。比如：
http://dir./gmane.linux.kernel
強(qiáng)烈建議你在向列表發(fā)郵件詢問(wèn)之前，先在存檔中搜索一下你想問(wèn)的話題。很多事情都已經(jīng)詳細(xì)的討論過(guò)了，它們只在郵件列表存檔中有記錄。
很多內(nèi)核子系統(tǒng)也有它們單獨(dú)的郵件列表，在那里開(kāi)發(fā)者們做他們的開(kāi)發(fā)工作。請(qǐng)查看MAINTAINER文件來(lái)找到這些不同子系統(tǒng)的郵件列表。
很多郵件列表放置于之上。有關(guān)它們的信息可以在這里找到：
http://vger./vger-lists.html
請(qǐng)記住在使用這些列表時(shí)請(qǐng)遵守良好的行為習(xí)慣。下面的URL有一些如何在郵件列表上與人交流的簡(jiǎn)單的準(zhǔn)則，雖然有一點(diǎn)俗氣：http://www./netiquette
如果有許多人回復(fù)你的郵件，收件人的抄送列表會(huì)變得很長(zhǎng)。在沒(méi)有一個(gè)合理的理由時(shí)不要把任何人從抄送列表中去掉，或者不要只回復(fù)被列出的地址。要對(duì)于收到同一封信兩次感到習(xí)慣，一次從發(fā)信者，一次從郵件列表。不要為了好看而加上別致的郵件頭部，人們不喜歡這樣。
記得保證你的回復(fù)的上下文和屬性的完整性，在你的回復(fù)的最上方保留類似 “John Kernelhacker wrote ...“的字樣，把你的回復(fù)寫在被引用的段落之間，而不要寫在郵件的最上方。
如果你在你的郵件里加入了補(bǔ)丁，要確保它們是純文本，就象Do*****entation/SubmittingPatches里所說(shuō)的。內(nèi)核開(kāi)發(fā)者不希望處理附件或者壓縮的補(bǔ)??；他們會(huì)希望評(píng)價(jià)你的補(bǔ)丁的每一行，只有純文本才符合這個(gè)要求。
確保你使用的郵件客戶端軟件不會(huì)破壞空格和制表符。你可以發(fā)一個(gè)郵件給你自己，然后應(yīng)用你自己的補(bǔ)丁來(lái)先做個(gè)測(cè)試。如果不行，修復(fù)你的郵件程序或者換一個(gè)。
最重要的一點(diǎn)，請(qǐng)記得顯示出你對(duì)其他訂閱者的尊重。
和社區(qū)一起工作
內(nèi)核社區(qū)的目標(biāo)是提供可能提供的最好的內(nèi)核。當(dāng)你提交了一個(gè)補(bǔ)丁等待被收錄時(shí)，它會(huì)被且僅被該領(lǐng)域的技術(shù)權(quán)威所檢查。所以，你應(yīng)該期待什么呢？
－ 批評(píng)
－ 評(píng)論
－ 被要求改動(dòng)
－ 被要求解釋
－ 沉默
記住，這是讓你的補(bǔ)丁進(jìn)入內(nèi)核的一部分。你必須能夠接受對(duì)你的補(bǔ)丁的批評(píng)和評(píng)論，在技術(shù)的層面上評(píng)估它，然后要么對(duì)你的補(bǔ)丁作出修改，要么提供清晰而言簡(jiǎn)意賅的理由解釋為什么不應(yīng)該做改動(dòng)。如果沒(méi)有對(duì)你的補(bǔ)丁的回復(fù)，等幾天再試一次，有時(shí)候在流量很大的時(shí)候信件可能丟失，或被人忽略遺忘了。
你不應(yīng)該做什么：

－ 期待你的補(bǔ)丁沒(méi)有任何疑問(wèn)的被接受 － 不接受批評(píng)，不承認(rèn)缺點(diǎn) － 忽略評(píng)論 － 在不做任何修改的情況下再次提交補(bǔ)丁

在一個(gè)尋找可能存在的最好的技術(shù)解決方案的社區(qū)里，關(guān)于一個(gè)補(bǔ)丁怎樣的有用必定會(huì)存在不同的意見(jiàn)。你應(yīng)該采取合作的態(tài)度，愿意改變你的意見(jiàn)以適應(yīng)內(nèi)核的需要?；蛘咧辽僭敢庾C明的你的觀點(diǎn)有價(jià)值。記住，犯錯(cuò)誤是可以接受的，只要你愿意朝著正確的解決方案努力。
如果對(duì)于你的第一個(gè)補(bǔ)丁的回應(yīng)只是一些要求你改正的意見(jiàn)，這很正常。這并不意味著你的補(bǔ)丁將不會(huì)被接受，這些意見(jiàn)也不是針對(duì)你本人的。你要做的只是改正你的補(bǔ)丁然后重新發(fā)送。
內(nèi)核社區(qū)和企業(yè)架構(gòu)的區(qū)別
------------------------
內(nèi)核社區(qū)和大多數(shù)傳統(tǒng)的企業(yè)開(kāi)發(fā)環(huán)境工作形式不一樣。這里有一個(gè)列表你可以嘗試遵照?qǐng)?zhí)行以避免出現(xiàn)問(wèn)題：
關(guān)于你提交的補(bǔ)丁的好的說(shuō)法：

－ “這個(gè)可以解決多個(gè)問(wèn)題。” － “這個(gè)刪除了2000行代碼。” － “這個(gè)補(bǔ)丁解釋了我嘗試想描述的東西。” － “我在5個(gè)不同的架構(gòu)上測(cè)試了它……” － “這里是一系列的小補(bǔ)丁，它們可以……” － “這個(gè)在典型的機(jī)器上可以提高表現(xiàn)……”

你應(yīng)該避免的壞的說(shuō)法：

－ “我們?cè)贏IX/ptx/Solaris上都是這樣做的，所以它一定是好的……” － “我已經(jīng)這樣做20年了，所以……” － “我的公司需要這樣做來(lái)掙錢” － “這是我的一千頁(yè)的設(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è)不同是沒(méi)有面對(duì)面的交流。使用email和irc作為主要交流形式的好處之一是不會(huì)存在基于性別或者種族的歧視。Linux內(nèi)核工作環(huán)境接受女士和少數(shù)民族，因?yàn)槟愕拇嬖谥皇且粋€(gè)email地址。國(guó)際化也幫助我們實(shí)現(xiàn)了平等的工作環(huán)境，因?yàn)槟銦o(wú)法根據(jù)一個(gè)人的名字來(lái)判斷一個(gè)人的性別。一個(gè)男人可以叫Andrea，一個(gè)女人可以叫Pat。大多數(shù)為L(zhǎng)inux內(nèi)核做過(guò)工作或者發(fā)表過(guò)觀點(diǎn)的女性對(duì)此都深有體會(huì)。
對(duì)于不習(xí)慣英語(yǔ)的人來(lái)說(shuō)語(yǔ)言障礙可能會(huì)導(dǎo)致一些問(wèn)題。對(duì)于語(yǔ)言的良好的掌握可以令思想在郵件列表上交流的更暢通，所以建議你在發(fā)送郵件之前檢查一下你的郵件內(nèi)容在英語(yǔ)里是否有意義。
打散你的補(bǔ)丁
Linux內(nèi)核社區(qū)不樂(lè)意接受大段的代碼，一般會(huì)在收到時(shí)立刻丟棄。你的補(bǔ)丁需要適當(dāng)?shù)谋唤榻B，討論，并打散為細(xì)小的，獨(dú)立的片段。這幾乎和公司里經(jīng)常做的完全背道而馳。你的提議必須在開(kāi)發(fā)流程的早期提出，這樣你才可以收到足夠的關(guān)于你的工作的回饋。這也會(huì)令社區(qū)感覺(jué)到你是在和他們一起工作，而不是利用他們作為傾倒你的補(bǔ)丁的場(chǎng)所。但是，請(qǐng)不要一次向郵件列表發(fā)送超過(guò)50封email，你的一系列補(bǔ)丁的個(gè)數(shù)應(yīng)該永遠(yuǎn)小于這個(gè)數(shù)字。
把補(bǔ)丁打散的理由如下：
1) 小的補(bǔ)丁增加了你的補(bǔ)丁被應(yīng)用的機(jī)會(huì)，因?yàn)樗恍枰ㄌ嗟臅r(shí)間和精力來(lái)檢查它的正確性。一個(gè)5行的補(bǔ)丁，一個(gè)維護(hù)者只要花一秒鐘瞟一眼然后就可以應(yīng)用了。不過(guò)，一個(gè)500行的補(bǔ)丁需要一個(gè)小時(shí)來(lái)檢查是否有錯(cuò)誤（所需的時(shí)間跟補(bǔ)丁的大小差不多成指數(shù)級(jí)別增長(zhǎng)）。小補(bǔ)丁也使得在出錯(cuò)的時(shí)候很容易 debug。如果出了問(wèn)題，小補(bǔ)丁可以一個(gè)一個(gè)的取消，大補(bǔ)丁就比較麻煩了。
2) 除了要把補(bǔ)丁打散之外，在提交之前還要重寫和簡(jiǎn)化（或者只是簡(jiǎn)單的重排序）你的補(bǔ)丁。這一點(diǎn)也是很重要的。
這里有一個(gè)內(nèi)核開(kāi)發(fā)者Al Viro所做的類比： “想一下一個(gè)老師為一個(gè)數(shù)學(xué)系學(xué)生批改作業(yè)的情景。老師不希望看到學(xué)生在回答出正確答案之前的嘗試和失敗。他們想看到最清楚的，最優(yōu)美的答案。一個(gè)好學(xué)生了解這一點(diǎn)，并不會(huì)在得到最終答案之前把他們的中間結(jié)果提交上去。對(duì)于內(nèi)核開(kāi)發(fā)來(lái)說(shuō)同樣是這樣。維護(hù)者和評(píng)論者不希望看到問(wèn)題的解決方案背后的思考過(guò)程。他們想看到一個(gè)簡(jiǎn)單和優(yōu)美的解決方案。”
提供一個(gè)優(yōu)美的解決方案和同社區(qū)一起工作討論你未完成的作品，要維持此二者之間的平衡可能是一個(gè)很有挑戰(zhàn)性的事情。所以應(yīng)及早的參與一個(gè)開(kāi)發(fā)流程以獲得回饋來(lái)改進(jìn)你的作品，但仍要保證你的補(bǔ)丁的小塊頭，這樣它們可能提早被接受，哪怕是在你的整個(gè)作品還為完成時(shí)。
也請(qǐng)注意，如果你的補(bǔ)丁尚未完成而且還需要修改，請(qǐng)不要提交。
證明你的改動(dòng)
除了打散你的補(bǔ)丁之外，讓Linux社區(qū)理解為什么他們要加入這項(xiàng)改動(dòng)也是很重要的。新的功能必須要被證實(shí)它們需要而且有用。
為你的改動(dòng)寫文檔
在你提交補(bǔ)丁時(shí)，要格外留心你在email里說(shuō)的話。這些信息將會(huì)成為這個(gè)補(bǔ)丁的ChangeLog信息，將會(huì)被保留從而使每個(gè)人任何時(shí)候都可以看到。它必須完整的描述這個(gè)補(bǔ)丁，包括：

－ 為什么這個(gè)改動(dòng)是需要的 － 這個(gè)補(bǔ)丁的整體設(shè)計(jì)方案 － 實(shí)現(xiàn)細(xì)節(jié) － 測(cè)試結(jié)果

欲知這個(gè)過(guò)程到底看起來(lái)是什么樣子的，請(qǐng)看這個(gè)文檔的ChangeLog部分： “The Perfect Patch”
http://www./~akpm/linux/patches/stuff/tpp.txt
所有這些事情有時(shí)候很難做到。要想完美做到這些要求可能需要幾年的時(shí)間。這是一個(gè)持續(xù)的發(fā)展過(guò)程，需要很多耐心和決心。但是不要放棄，這是可以實(shí)現(xiàn)的。很多人已經(jīng)做到了這一點(diǎn)，每個(gè)人都經(jīng)歷過(guò)你現(xiàn)在這個(gè)階段。

（責(zé)任編輯：城塵 68476636-8003）