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

1、.轉(zhuǎn) 如何成為一個(gè)Linux內(nèi)核開發(fā)者如何成為一個(gè)Linux內(nèi)核開發(fā)者閱讀提示：本文將教你如何成為一個(gè)Linux內(nèi)核開發(fā)者以及學(xué)會(huì)如何和Linux內(nèi)核社區(qū)一起工作。它不包含任何有關(guān)內(nèi)核編程的技術(shù)細(xì)節(jié)，但是會(huì)幫你在這方面指明方向。你想成知道如何成為一個(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ā)

2、的必備條件。匯編語言任何架構(gòu)的理解不是必須的，除非你準(zhǔn)備做某個(gè)架構(gòu)的底層開發(fā)。雖然下面這些書不能完全代替扎實(shí)的C語言教學(xué)和/或者成年累月的經(jīng)歷，他們還是不錯(cuò)的參考，假設(shè)用得著的話：-"The CProgramming Language" Kernighan and RitchiePrentice Hall-"Practical CProgramming" Steve OuallineO'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庫，所

3、以某些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ā)布。

4、請參考源代碼樹下的COPYING文件，以獲取有關(guān)這個(gè)容許證的詳細(xì)信息。假設(shè)你對這個(gè)容許證有疑問，請聯(lián)絡(luò)你的律師，不要在Linux內(nèi)核郵件列表里詢問。郵件列表里的人們不是律師，你不應(yīng)該依賴于他們對于法律問題的解釋。欲理解有關(guān)GPL的常見問題和答案，請看：文檔Linux內(nèi)核源代碼樹有很多文檔，它們對于學(xué)習(xí)如何與內(nèi)核社區(qū)交流來說有不可估量的價(jià)值。當(dāng)新的功能加進(jìn)內(nèi)核的時(shí)候，通常建議作者把解釋這個(gè)新功能的文檔也加進(jìn)內(nèi)核。假設(shè)一個(gè)內(nèi)核變動(dòng)導(dǎo)致了內(nèi)核對用戶空間界面的改變，建議你把這個(gè)信息或者一個(gè)解釋了這個(gè)變動(dòng)的manpage的補(bǔ)丁發(fā)送給手冊頁的維護(hù)者mtk-manpages。這里有一個(gè)內(nèi)核源代碼樹里需要閱讀

5、的文件列表：README這個(gè)文件簡單介紹了Linux內(nèi)核的背景，并描繪了配置和編譯內(nèi)核需要做哪些事情。內(nèi)核新手應(yīng)該從這里開場。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ā)送

6、一個(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"kernle patch submission format"這個(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人也是很

7、重要的。Do*entation/SecurityBugs假設(shè)你感覺到你發(fā)現(xiàn)了Linux內(nèi)核里的一個(gè)平安問題，請遵照這個(gè)文檔里所描繪的步驟來提醒內(nèi)核開發(fā)者，并幫助解決問題。Do*entation/ManagementStyle這個(gè)文檔描繪了Linux內(nèi)核維護(hù)者如何運(yùn)作，以及他們?yōu)槭裁催@樣做。它對于任何內(nèi)核開發(fā)新手或者任何對本話題感興趣的人來說是非常重要的。因?yàn)樗忉屃艘恍T有的錯(cuò)誤概念，可解決有關(guān)內(nèi)核維護(hù)者獨(dú)特行為的疑惑。Do*entation/stable_kernel_rules.txt本文件描繪了穩(wěn)定版本內(nèi)核釋出的規(guī)那么，還有假設(shè)你想對其中的一個(gè)版本做一些改動(dòng)應(yīng)該做些什么。Do*entat

8、ion/kernel-docs.txt一個(gè)有關(guān)內(nèi)核開發(fā)的外部文檔的列表。假設(shè)你在內(nèi)核內(nèi)部文檔里沒有找到?要找的東西，你可以參考這個(gè)列表。Do*entation/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)立于Do*entation/DocBook/文件夾中。在內(nèi)核主源碼樹中通過運(yùn)行下面的命令可以創(chuàng)立出PDF，Postscript，HTML和manpage等不同格式的文檔：make pdfdocs make psdocs mak

9、e htmldocs make mandocs成為一個(gè)內(nèi)核開發(fā)者假設(shè)你對Linux內(nèi)核開發(fā)一無所知，你可以看看Linux KernelNewbies工程：它包含一個(gè)郵件列表，在那里你可以問任何有關(guān)內(nèi)核開發(fā)的根底問題在問問題之前先搜索一下存檔，很可能這個(gè)問題已經(jīng)被解答過了。它還有一個(gè)IRC頻道，你可以在里面實(shí)時(shí)的提問。它還有很多有用的文檔，對于學(xué)習(xí)Linux內(nèi)核開發(fā)很有用。這個(gè)網(wǎng)站有有關(guān)代碼組織，子系統(tǒng)，當(dāng)前工程代碼樹之內(nèi)的和之外的的根本信息。它也描繪了一些根本的"物流"信息，比方怎么樣編譯內(nèi)核和怎么樣打補(bǔ)丁。假設(shè)你不知道從何處起步，但是你想找一些任務(wù)來做以參加內(nèi)核開發(fā)社區(qū)，

10、請看一下Linux Kernel Janitor工程：這是一個(gè)很好的起步的地方。它描繪了一些相對來說簡單的內(nèi)核中需要清理的和解決的問題。和負(fù)責(zé)這個(gè)工程的開發(fā)者一起工作，你會(huì)學(xué)到如何令你的補(bǔ)丁進(jìn)入Linux內(nèi)核樹的根本知識，而且可能會(huì)為你指明下一步的開展方向，假設(shè)你自己尚不明確的話。假設(shè)你已經(jīng)有了一段代碼想要放到內(nèi)核樹里，但是需要某種形式的幫助，那么kernel-mentors工程就可以幫你的忙了。這是一個(gè)郵件列表，可以在下面找到：在你對Linux內(nèi)核代碼作任何實(shí)際的改動(dòng)之前，必需要理解相關(guān)的代碼是如何工作的。為了到達(dá)這個(gè)目的，沒有比直接讀它很多困難的地方都有很好的注釋更好的方法了，甚至可能是在

11、某個(gè)特殊工具的幫助下來閱讀。很值得推薦的這樣一種工具是Linux Cross-Reference工程，它可以把源代碼以一種自我引用的、索引的網(wǎng)頁形式顯示出來。一個(gè)非常好的最新的內(nèi)核代碼倉庫可以在這里找到：開發(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ù)的，可以在的pub/linux/kernel/v2.6目錄里找到。它的開發(fā)流程

12、是這樣的：-當(dāng)一個(gè)新的內(nèi)核發(fā)布之后，一個(gè)為期兩個(gè)星期的窗口翻開，在這段時(shí)間里維護(hù)者可以提交大的補(bǔ)丁給Linus，通常是已經(jīng)在-mm內(nèi)核中存在了一定時(shí)間的補(bǔ)丁。推薦的提交補(bǔ)丁的方式是通過git有關(guān)git的更多信息可以在找到，但是普通的補(bǔ)丁也是可以的-兩個(gè)星期之后一個(gè)-rc1內(nèi)核發(fā)布，然后如今只可以再參加不會(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è)公開的郵件列表

13、里以備審查。-當(dāng)Linus確信當(dāng)前的git內(nèi)核代碼管理工具樹已經(jīng)處于一個(gè)合理的健全狀態(tài)，足夠測試時(shí)，一個(gè)新的-rc就會(huì)發(fā)布了。目的是每周發(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)樗l(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)核中

14、發(fā)現(xiàn)的平安問題或者重大的回歸。對于想使用最新的穩(wěn)定內(nèi)核并且對于幫助測試開發(fā)/實(shí)驗(yàn)版本不感興趣的用戶，這是推薦使用的版本。假設(shè)沒有2.6.x.y版本，那么最高版本號的2.6.x內(nèi)核是當(dāng)前穩(wěn)定內(nèi)核。2.6.x.y由"stable"團(tuán)隊(duì)維護(hù)，每周發(fā)布一次。內(nèi)核樹里的文件Do*entation/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)生

15、成的，以致沒有人曾經(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ǔ)丁，把它們交融在一起。這個(gè)樹是新功能和補(bǔ)丁證明自己的場所。假設(shè)一個(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)性。假設(shè)你想幫助內(nèi)核開發(fā)流程，請測試并使

16、用這些內(nèi)核發(fā)布，并在linux-kernel郵件列表里提供回饋，假設(shè)你發(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ā)布方案，但是通常在每兩個(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 ：/pub/scm/lin

17、ux/kernel/git/sam/kbuild.git-ACPI開發(fā)樹,Len Brown ：/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6.git-塊設(shè)備開發(fā)樹,Jens Axboe ：/pub/scm/linux/kernel/git/axboe/linux-2.6-block.git-DRM開發(fā)樹,Dave Airlie ：/pub/scm/linux/kernel/git/airlied/drm-2.6.git-ia64開發(fā)樹,Tony Luck ：/pub/s

18、cm/linux/kernel/git/aegl/linux-2.6.git-ieee1394開發(fā)樹,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 Garzi

19、k ：/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)核樹可以在找到quilt trees：-USB,PCI,Driver Core,and I2C,Gre gKroah-Hartman ke

20、/pub/linux/kernel/people/gregkh/gregkh-2.6/報(bào)告Bug 是Linux內(nèi)核開發(fā)者追蹤內(nèi)核bug的地方。我們鼓勵(lì)用戶在這個(gè)工具中報(bào)告他們發(fā)現(xiàn)的所有bug。欲知使用內(nèi)核bugzilla的詳細(xì)細(xì)節(jié)，請看：主內(nèi)核源碼目錄中的REPORTING-BUGS文件有一個(gè)報(bào)告可能有的內(nèi)核bug的模板，并詳細(xì)講述了內(nèi)核開發(fā)者需要什么樣的信息，以便他們可追蹤到問題所在。郵件列表就像上面的一些文檔所描繪的，大多數(shù)核心內(nèi)核開發(fā)者參與Linux內(nèi)核郵件列表的討論。如何訂閱和取消訂閱這個(gè)列表的細(xì)節(jié)可以從這里找到：網(wǎng)上很多地方都有這

21、個(gè)郵件列表的存檔。使用一個(gè)搜索引擎來搜索這些存檔。比方：強(qiáng)烈建議你在向列表發(fā)郵件詢問之前，先在存檔中搜索一下你想問的話題。很多事情都已經(jīng)詳細(xì)的討論過了，它們只在郵件列表存檔中有記錄。很多內(nèi)核子系統(tǒng)也有它們單獨(dú)的郵件列表，在那里開發(fā)者們做他們的開發(fā)工作。請查看MAINTAINER文件來找到這些不同子系統(tǒng)的郵件列表。很多郵件列表放置于之上。有關(guān)它們的信息可以在這里找到：請記住在使用這些列表時(shí)請遵守良好的行為習(xí)慣。下面的URL有一些如何在郵件列表上與人交流的簡單的準(zhǔn)那么，雖然有一點(diǎn)俗氣：假設(shè)有許多人回復(fù)你的郵件，收件人的抄送列表會(huì)變得很長。在沒有一個(gè)合理的理由時(shí)不要把任何人從抄送

22、列表中去掉，或者不要只回復(fù)被列出的地址。要對于收到同一封信兩次感到習(xí)慣，一次從發(fā)信者，一次從郵件列表。不要為了好看而加上別致的郵件頭部，人們不喜歡這樣。記得保證你的回復(fù)的上下文和屬性的完好性，在你的回復(fù)的最上方保存類似"John Kernelhacker wrote."的字樣，把你的回復(fù)寫在被引用的段落之間，而不要寫在郵件的最上方。假設(shè)你在你的郵件里參加了補(bǔ)丁，要確保它們是純文本，就象Do*entation/SubmittingPatches里所說的。內(nèi)核開發(fā)者不希望處理附件或者壓縮的補(bǔ)??；他們會(huì)希望評價(jià)你的補(bǔ)丁的每一行，只有純文本才符合這個(gè)要求。確保你使用的郵件客戶端軟件

23、不會(huì)破壞空格和制表符。你可以發(fā)一個(gè)郵件給你自己，然后應(yīng)用你自己的補(bǔ)丁來先做個(gè)測試。假設(shè)不行，修復(fù)你的郵件程序或者換一個(gè)。最重要的一點(diǎn)，請記得顯示出你對其他訂閱者的尊重。和社區(qū)一起工作內(nèi)核社區(qū)的目的是提供可能提供的最好的內(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)。假設(shè)沒有對你的補(bǔ)丁的回復(fù)，等幾天再試一次，有時(shí)候在流量很大的時(shí)候

24、信件可能喪失，或被人忽略遺忘了。你不應(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ò)誤是可以承受的，只要你愿意朝著正確的解決方案努力。假設(shè)對于你的第一個(gè)補(bǔ)丁的回應(yīng)只是一些要求你改正的意見，這很正常。這并不意味著你的補(bǔ)丁將不會(huì)被承受，這些意見也不是針對你本人的。你要做的只是改正你的補(bǔ)丁然后重新發(fā)送。內(nèi)核社區(qū)和企業(yè)架構(gòu)的區(qū)別-內(nèi)核社區(qū)和大多數(shù)

25、傳統(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ī)器上可以進(jìn)步表現(xiàn)"你應(yīng)該防止的壞的說法：-"我們在AIX/ptx/Solaris上都是這樣做的，所以它一定是好的"-"我已經(jīng)這樣做20年了，所以&quo

26、t;-"我的公司需要這樣做來掙錢"-"這是我的一千頁的設(shè)計(jì)文檔，它解釋了我的想法"-"我已經(jīng)在它上面花了6個(gè)月的心血"-"這里是一個(gè)5000行的補(bǔ)丁，它"-"我重新寫了所有現(xiàn)有的垃圾，在這里"-"我有完成期限，這個(gè)補(bǔ)丁必須如今被應(yīng)用。"內(nèi)核社區(qū)和大多數(shù)傳統(tǒng)軟件工程工作環(huán)境的另一個(gè)不同是沒有面對面的交流。使用email和irc作為主要交流形式的好處之一是不會(huì)存在基于性別或者種族的歧視。Linux內(nèi)核工作環(huán)境承受女士和少數(shù)民族，因?yàn)槟愕拇嬖谥皇且粋€(gè)email地址。國際化也幫助我們

27、實(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)用的時(shí)機(jī)，因?yàn)樗恍枰ㄌ嗟臅r(shí)間和精力來檢查它的正確性。一個(gè)5行的補(bǔ)丁，一個(gè)維護(hù)者只要花一秒鐘瞟一眼然后就可以應(yīng)