作者: 出處:51CTO論壇 ( 1 ) 磚 ( 2 ) 好
評論 ( 0 ) 條進(jìn)入論壇更新時(shí)間：
2006-08-29 08:56關(guān) 鍵 詞：
Linux閱讀提示：本文將教你如何成為一個(gè)Linux內核開(kāi)發(fā)者以及學(xué)會(huì )如何和Linux內核社區一起工作。它不包含任何有關(guān)內核編程的技術(shù)細節，但是會(huì )幫你在這方面指明方向。
你想成知道如何成為一個(gè)Linux內核開(kāi)發(fā)者么？或者你的老板告訴你，“去為這個(gè)設備寫(xiě)一個(gè)Linux驅動(dòng)。“這篇文檔的目的，就是通過(guò)描述你需要經(jīng)歷的過(guò)程和提示你如何和社區一起工作，來(lái)教給你為達到這些目的所需要知道的所有知識。本文也嘗試解釋社區為什么這樣工作的一些原因。
內核幾乎全是用C寫(xiě)成的，有一些架構相關(guān)的部分是用匯編語(yǔ)言寫(xiě)成的。熟練掌握C語(yǔ)言是內核開(kāi)發(fā)的必備條件。匯編語(yǔ)言（任何架構）的了解不是必須的，除非你準備做某個(gè)架構的底層開(kāi)發(fā)。雖然下面這些書(shū)不能完全代替扎實(shí)的C語(yǔ)言教學(xué)和/或者成年累月的經(jīng)驗，他們還是不錯的參考，如果用得著(zhù)的話(huà)：
- "The C Programming Language"
作者: Kernighan and Ritchie [Prentice Hall]
- "Practical C Programming"
作者: Steve Oualline [O'Reilly]
內核是用 GNU C 和 GNU 工具鏈寫(xiě)成的。雖然它符合 ISO C89 標準，它還是使用了一些標準中沒(méi)有的擴展。內核是自成體系的 C 環(huán)境，它并不依賴(lài)標準C庫，所以某些C語(yǔ)言標準是不支持的。任意長(cháng)度long long類(lèi)型除法和浮點(diǎn)數是不被允許的。有時(shí)候會(huì )很難理解內核對于它所使用的工具鏈和擴展的假定，而且不幸的是也沒(méi)有關(guān)于它們的絕對的參考。請查閱gcc 的info頁(yè)(`info gcc`)以獲取有關(guān)信息。
請記住你是在嘗試學(xué)習如何與已經(jīng)存在的開(kāi)發(fā)社區一起工作。這是一群成分復雜的人們，他們對于代碼，風(fēng)格和步驟有高的標準。這些標準是經(jīng)過(guò)時(shí)間檢驗的。
他們發(fā)現遵循這些標準對于這樣一個(gè)大規模的且地理上分散的團隊是最佳的選擇。嘗試提前學(xué)習盡可能多的有關(guān)這些標準的知識，因為它們都有很好的文檔；不要期望別人會(huì )遵照你或者你公司的行事方式。
法律問(wèn)題
Linux內核源代碼依照GPL發(fā)布。請參考源代碼樹(shù)下的COPYING文件，以獲取有關(guān)這個(gè)許可證的詳細信息。如果你對這個(gè)許可證有疑問(wèn)，請聯(lián)系你的律師，不要在Linux內核郵件列表里詢(xún)問(wèn)。郵件列表里的人們不是律師，你不應該依賴(lài)于他們對于法律問(wèn)題的解釋。
欲了解有關(guān)GPL的常見(jiàn)問(wèn)題和答案，請看：
http://www.gnu.org/licenses/gpl-faq.html文檔
Linux內核源代碼樹(shù)有很多文檔，它們對于學(xué)習如何與內核社區交流來(lái)說(shuō)有不可估量的價(jià)值。當新的功能加進(jìn)內核的時(shí)候，通常建議作者把解釋這個(gè)新功能的文檔也加進(jìn)內核。如果一個(gè)內核變動(dòng)導致了內核對用戶(hù)空間界面的改變，建議你把這個(gè)信息或者一個(gè)解釋了這個(gè)變動(dòng)的manpage的補丁發(fā)送給手冊頁(yè)的維護者
mtk-manpages@gmx.net。
這里有一個(gè)內核源代碼樹(shù)里需要閱讀的文件列表：
README
這個(gè)文件簡(jiǎn)單介紹了Linux內核的背景，并描述了配置和編譯內核需要做哪些事情。內核新手應該從這里開(kāi)始。
Do*****entation/Changes
這個(gè)文件介紹了成功編譯和運行內核所需要各種不同軟件的列表。
Do*****entation/CodingStyle
這個(gè)文件描述了Linux內核代碼風(fēng)格，還有背后的一些原因。所有的新代碼的要符合這個(gè)文檔里的準則。大多數維護者只會(huì )接受符合這些規則的補丁，很多人只看符合正確風(fēng)格的代碼。
Do*****entation/SubmittingPatches
Do*****entation/SubmittingDrivers
這些文件非常詳細的介紹了如何成功的創(chuàng )建和發(fā)送一個(gè)補丁，包括（但不限于）：
－Email內容
－Email格式
－發(fā)送給誰(shuí)
遵守所有這些規則并不能保證成功（對所有的補丁都需要進(jìn)行內容和風(fēng)格的詳細檢查），但是不遵守這些規則就一定不會(huì )成功。
其他關(guān)于如何創(chuàng )建補丁的很好的文章有：
“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.htmlDo*****entation/stable_api_nonsense.txt
這個(gè)文件解釋了有意識的決定－不在內核里使用穩定的API－的原因，包括：
－子系統分隔層（為了兼容？）
－操作系統之間的驅動(dòng)可移植性
－緩和（或者阻止）內核源代碼樹(shù)的急速變動(dòng)
這個(gè)文檔對于了解Linux的開(kāi)發(fā)哲學(xué)是非常關(guān)鍵的，對于由開(kāi)發(fā)其他操作系統轉而開(kāi)發(fā)Linux人也是很重要的。
Do*****entation/SecurityBugs
如果你感覺(jué)到你發(fā)現了Linux內核里的一個(gè)安全問(wèn)題，請遵照這個(gè)文檔里所描述的步驟來(lái)提醒內核開(kāi)發(fā)者，并幫助解決問(wèn)題。
Do*****entation/ManagementStyle
這個(gè)文檔描述了Linux內核維護者如何運作，以及他們?yōu)槭裁催@樣做。它對于任何內核開(kāi)發(fā)新手（或者任何對本話(huà)題感興趣的人）來(lái)說(shuō)是非常重要的。
因為它解釋了一些慣有的錯誤概念，可解決有關(guān)內核維護者獨特行為的疑惑。
Do*****entation/stable_kernel_rules.txt
本文件描述了穩定版本內核釋出的規則，還有如果你想對其中的一個(gè)版本做一些改動(dòng)應該做些什么。
Do*****entation/kernel-docs.txt
一個(gè)有關(guān)內核開(kāi)發(fā)的外部文檔的列表。如果你在內核內部文檔里沒(méi)有找到? 要找的東西，你可以參考這個(gè)列表。
Do*****entation/applying-patches.txt
介紹了對于什么是補丁，以及如何應用補丁于不同的內核開(kāi)發(fā)分支。
內核也有很多可以從源代碼自動(dòng)產(chǎn)生的文檔。這包括內核內部API的全面描述，有關(guān)如何處理好鎖定的規則。這些文檔會(huì )被創(chuàng )建于 Do*****entation/DocBook/文件夾中。在內核主源碼樹(shù)中通過(guò)運行下面的命令可以創(chuàng )建出PDF，Postscript， HTML和manpage等不同格式的文檔： make pdfdocs
make psdocs
make htmldocs
make mandocs
成為一個(gè)內核開(kāi)發(fā)者
如果你對Linux內核開(kāi)發(fā)一無(wú)所知，你可以看看Linux KernelNewbies項目：
http://kernelnewbies.org它包含一個(gè)郵件列表，在那里你可以問(wèn)任何有關(guān)內核開(kāi)發(fā)的基礎問(wèn)題（在問(wèn)問(wèn)題之前先搜索一下存檔，很可能這個(gè)問(wèn)題已經(jīng)被解答過(guò)了。）它還有一個(gè)IRC頻道，你可以在里面實(shí)時(shí)的提問(wèn)。它還有很多有用的文檔，對于學(xué)習Linux內核開(kāi)發(fā)很有用。
這個(gè)網(wǎng)站有有關(guān)代碼組織，子系統，當前項目（代碼樹(shù)之內的和之外的）的基本信息。它也描述了一些基本的“物流”信息，比如怎么樣編譯內核和怎么樣打補丁。
如果你不知道從何處起步，但是你想找一些任務(wù)來(lái)做以加入內核開(kāi)發(fā)社區，請看一下Linux Kernel Janitor項目：
http://janitor.kernelnewbies.org/這是一個(gè)很好的起步的地方。它描述了一些相對來(lái)說(shuō)簡(jiǎn)單的內核中需要清理的和解決的問(wèn)題。和負責這個(gè)項目的開(kāi)發(fā)者一起工作，你會(huì )學(xué)到如何令你的補丁進(jìn)入Linux內核樹(shù)的基本知識，而且可能會(huì )為你指明下一步的發(fā)展方向，如果你自己尚不明確的話(huà)。
如果你已經(jīng)有了一段代碼想要放到內核樹(shù)里，但是需要某種形式的幫助，那么kernel-mentors項目就可以幫你的忙了。這是一個(gè)郵件列表，可以在下面找到：
http://selenic.com/mailman/listinfo/kernel-mentors在你對Linux內核代碼作任何實(shí)際的改動(dòng)之前，必須要了解相關(guān)的代碼是如何工作的。為了達到這個(gè)目的，沒(méi)有比直接讀它（很多困難的地方都有很好的注釋?zhuān)└玫姆椒?，甚至可能是在某個(gè)特殊工具的幫助下來(lái)閱讀。很值得推薦的這樣一種工具是Linux Cross-Reference項目，它可以把源代碼以一種自我引用的、索引的網(wǎng)頁(yè)形式顯示出來(lái)。一個(gè)非常好的最新的內核代碼倉庫可以在這里找到：
http://sosdg.org/~coywolf/lxr開(kāi)發(fā)流程
Linux內核開(kāi)發(fā)流程當前包括一些主內核分支，和很多不同的子系統專(zhuān)有的內核分支。它們是： － 主 2.6.x 內核樹(shù)
－ 2.6.x.y -stable 內核樹(shù)
－ 2.6.x -git 內核補丁
－ 2.6.x -mm 內核補丁
－ 子系統專(zhuān)有內核樹(shù)和補丁
2.6.x 內核樹(shù)
2.6.x 內核樹(shù)是有Linus Torvalds維護的，可以在kernel.org的pub/linux/kernel/v2.6目錄里找到。它的開(kāi)發(fā)流程是這樣的：
－當一個(gè)新的內核發(fā)布之后，一個(gè)為期兩個(gè)星期的窗口打開(kāi)，在這段時(shí)間里維護者可以提交大的補丁給Linus，通常是已經(jīng)在-mm內核中存在了一定時(shí)間的補丁。推薦的提交補丁的方式是通過(guò)git（有關(guān)git的更多信息可以在
http://git.or.cz/找到），但是普通的補丁也是可以的－兩個(gè)星期之后一個(gè)-rc1內核發(fā)布，然后現在只可以再加入不會(huì )為內核添加新功能的補丁，因為那樣的補丁可能會(huì )影響這個(gè)內核的穩定性。請注意這個(gè)時(shí)候一個(gè)整的新驅動(dòng)（或者文件系統）可以被接受。因為只要這個(gè)變動(dòng)是自成一體的并且不影響它之外的代碼的話(huà)，就不會(huì )有產(chǎn)生回歸的危險。在-rc1發(fā)布之后，git可以用來(lái)發(fā)送補丁給Linus，但是這些補丁也需要發(fā)到一個(gè)公開(kāi)的郵件列表里以備審查。
－ 當Linus確信當前的git（內核代碼管理工具）樹(shù)已經(jīng)處于一個(gè)合理的健全狀態(tài)，足夠測試時(shí)，一個(gè)新的-rc就會(huì )發(fā)布了。目標是每周發(fā)布一個(gè)新的-rc內核。
－ 這個(gè)過(guò)程將會(huì )持續到內核被認為可以發(fā)布為止，整個(gè)流程會(huì )持續大概6個(gè)星期。
Andrew Morton在linux-kernel郵件列表里寫(xiě)的有關(guān)內核發(fā)布的一句話(huà)值得提一下： “沒(méi)有人知道什么時(shí)候一個(gè)內核會(huì )發(fā)布，因為它發(fā)布的依據已經(jīng)掌握的bug狀態(tài)，而不是事先設想好的一個(gè)時(shí)間線(xiàn)。
2.6.x.y -stable 內核樹(shù)
有四個(gè)數字版本號的內核是-stable內核。他們包含一些相對較小的和重要的修正。這些修正針對的是在一個(gè)給定2.6.x內核中發(fā)現的安全問(wèn)題或者重大的回歸。
對于想使用最新的穩定內核并且對于幫助測試開(kāi)發(fā)/實(shí)驗版本不感興趣的用戶(hù)，這是推薦使用的版本。
如果沒(méi)有2.6.x.y版本，那么最高版本號的2.6.x內核是當前穩定內核。
2.6.x.y由“stable”團隊維護，每周發(fā)布一次。
內核樹(shù)里的文件Do*****entation/stable_kernel_rules.txt描述了什么樣的改動(dòng)可以被-stable樹(shù)所接受，以及發(fā)布流程是怎樣工作的。
2.6.x -git 補丁
這些是在git倉庫里管理的Linus內核樹(shù)的每日快照。這些補丁每天發(fā)布一次，代表Linus樹(shù)的當前狀態(tài)。它們比-rc內核更具實(shí)驗性質(zhì)，因為它們是自動(dòng)生成的，以至沒(méi)有人曾經(jīng)瞟上一眼來(lái)檢查它們是否處于健全狀態(tài)。
2.6.x -mm 內核補丁
這些是Andrew Morton發(fā)布的實(shí)驗性質(zhì)的內核補丁。Andrew取得所有不同子系統的內核樹(shù)和補丁，連同從linux-kernel郵件列表里拉過(guò)來(lái)的補丁，把它們融合在一起。這個(gè)樹(shù)是新功能和補丁證明自己的場(chǎng)所。如果一個(gè)補丁在-mm里證實(shí)了自己的價(jià)值，Andrew或者子系統維護者就會(huì )把它提交給Linus，以求被收錄于主線(xiàn)內核中。
強烈建議所有的新補丁在發(fā)送給Linus之前都先發(fā)到-mm樹(shù)里測試一下。
打了此種補丁的內核不適用于追求穩定的系統中，運行它們比運行其他任何分支都更具冒險性。
如果你想幫助內核開(kāi)發(fā)流程，請測試并使用這些內核發(fā)布，并在linux-kernel郵件列表里提供回饋，如果你發(fā)現任何問(wèn)題的話(huà)，哪怕什么問(wèn)題也沒(méi)有。
在所有其他實(shí)驗性質(zhì)的補丁之外，這些內核補丁通常還會(huì )包含在發(fā)布時(shí)在主線(xiàn)-git內核中已經(jīng)包含的改動(dòng)。
-mm內核沒(méi)有一個(gè)固定的發(fā)布計劃，但是通常在每?jì)蓚€(gè)-rc內核發(fā)布間歇期會(huì )發(fā)布一些-mm內核（1到3個(gè)都很常見(jiàn)）。
子系統專(zhuān)有內核樹(shù)和補丁
一些不同的內核子系統開(kāi)發(fā)者公布他們的開(kāi)發(fā)樹(shù)，這樣其他人可以看到在內核的不同領(lǐng)域里正在發(fā)生什么。這些樹(shù)都會(huì )被包含在-mm內核發(fā)布中。
下面是一些不同的內核樹(shù)的列表： git樹(shù)：
- Kbuild 開(kāi)發(fā)樹(shù), Sam Ravnborg
kernel.org:/pub/scm/linux/kernel/git/sam/kbuild.git
- ACPI 開(kāi)發(fā)樹(shù), Len Brown
kernel.org:/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6.git
- 塊設備開(kāi)發(fā)樹(shù), Jens Axboe
kernel.org:/pub/scm/linux/kernel/git/axboe/linux-2.6-block.git
- DRM 開(kāi)發(fā)樹(shù), Dave Airlie
kernel.org:/pub/scm/linux/kernel/git/airlied/drm-2.6.git
- ia64 開(kāi)發(fā)樹(shù), Tony Luck
kernel.org:/pub/scm/linux/kernel/git/aegl/linux-2.6.git
- ieee1394 開(kāi)發(fā)樹(shù), Jody McIntyre
kernel.org:/pub/scm/linux/kernel/git/scjody/ieee1394.git
- infiniband, Roland Dreier
kernel.org:/pub/scm/linux/kernel/git/roland/infiniband.git
- libata, Jeff Garzik
kernel.org:/pub/scm/linux/kernel/git/jgarzik/libata-dev.git
- 網(wǎng)絡(luò )驅動(dòng), Jeff Garzik
kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git
- pcmcia, Dominik Brodowski
kernel.org:/pub/scm/linux/kernel/git/brodo/pcmcia-2.6.git
- SCSI, James Bottomley
kernel.org:/pub/scm/linux/kernel/git/jejb/scsi-misc-2.6.git
其他git內核樹(shù)可以在
http://kernel.org/git找到
quilt trees:
- USB, PCI, Driver Core, and I2C, Greg Kroah-Hartman
kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/
報告Bug
bugzilla.kernel.org是Linux內核開(kāi)發(fā)者追蹤內核bug的地方。我們鼓勵用戶(hù)在這個(gè)工具中報告他們發(fā)現的所有bug。欲知使用內核bugzilla的具體細節，請看：
http://test.kernel.org/bugzilla/faq.html主內核源碼目錄中的REPORTING-BUGS文件有一個(gè)報告可能有的內核bug的模板，并詳細講述了內核開(kāi)發(fā)者需要什么樣的信息，以便他們可追蹤到問(wèn)題所在。
郵件列表
就像上面的一些文檔所描述的，大多數核心內核開(kāi)發(fā)者參與Linux內核郵件列表的討論。如何訂閱和取消訂閱這個(gè)列表的細節可以從這里找到：
http://vger.kernel.org/vger-lists.html#linux-kernel網(wǎng)上很多地方都有這個(gè)郵件列表的存檔。使用一個(gè)搜索引擎來(lái)搜索這些存檔。比如：
http://dir.gmane.org/gmane.linux.kernel強烈建議你在向列表發(fā)郵件詢(xún)問(wèn)之前，先在存檔中搜索一下你想問(wèn)的話(huà)題。很多事情都已經(jīng)詳細的討論過(guò)了，它們只在郵件列表存檔中有記錄。
很多內核子系統也有它們單獨的郵件列表，在那里開(kāi)發(fā)者們做他們的開(kāi)發(fā)工作。請查看MAINTAINER文件來(lái)找到這些不同子系統的郵件列表。
很多郵件列表放置于kernel.org之上。有關(guān)它們的信息可以在這里找到：
http://vger.kernel.org/vger-lists.html請記住在使用這些列表時(shí)請遵守良好的行為習慣。下面的URL有一些如何在郵件列表上與人交流的簡(jiǎn)單的準則，雖然有一點(diǎn)俗氣：
http://www.albion.com/netiquette如果有許多人回復你的郵件，收件人的抄送列表會(huì )變得很長(cháng)。在沒(méi)有一個(gè)合理的理由時(shí)不要把任何人從抄送列表中去掉，或者不要只回復被列出的地址。要對于收到同一封信兩次感到習慣，一次從發(fā)信者，一次從郵件列表。不要為了好看而加上別致的郵件頭部，人們不喜歡這樣。
記得保證你的回復的上下文和屬性的完整性，在你的回復的最上方保留類(lèi)似 “John Kernelhacker wrote ...“的字樣，把你的回復寫(xiě)在被引用的段落之間，而不要寫(xiě)在郵件的最上方。
如果你在你的郵件里加入了補丁，要確保它們是純文本，就象Do*****entation/SubmittingPatches里所說(shuō)的。內核開(kāi)發(fā)者不希望處理附件或者壓縮的補??；他們會(huì )希望評價(jià)你的補丁的每一行，只有純文本才符合這個(gè)要求。
確保你使用的郵件客戶(hù)端軟件不會(huì )破壞空格和制表符。你可以發(fā)一個(gè)郵件給你自己，然后應用你自己的補丁來(lái)先做個(gè)測試。如果不行，修復你的郵件程序或者換一個(gè)。
最重要的一點(diǎn)，請記得顯示出你對其他訂閱者的尊重。
和社區一起工作
內核社區的目標是提供可能提供的最好的內核。當你提交了一個(gè)補丁等待被收錄時(shí)，它會(huì )被且僅被該領(lǐng)域的技術(shù)權威所檢查。所以，你應該期待什么呢？
－ 批評
－ 評論
－ 被要求改動(dòng)
－ 被要求解釋
－ 沉默
記住，這是讓你的補丁進(jìn)入內核的一部分。你必須能夠接受對你的補丁的批評和評論，在技術(shù)的層面上評估它，然后要么對你的補丁作出修改，要么提供清晰而言簡(jiǎn)意賅的理由解釋為什么不應該做改動(dòng)。如果沒(méi)有對你的補丁的回復，等幾天再試一次，有時(shí)候在流量很大的時(shí)候信件可能丟失，或被人忽略遺忘了。
你不應該做什么： － 期待你的補丁沒(méi)有任何疑問(wèn)的被接受
－ 不接受批評，不承認缺點(diǎn)
－ 忽略評論
－ 在不做任何修改的情況下再次提交補丁
在一個(gè)尋找可能存在的最好的技術(shù)解決方案的社區里，關(guān)于一個(gè)補丁怎樣的有用必定會(huì )存在不同的意見(jiàn)。你應該采取合作的態(tài)度，愿意改變你的意見(jiàn)以適應內核的需要?；蛘咧辽僭敢庾C明的你的觀(guān)點(diǎn)有價(jià)值。記住，犯錯誤是可以接受的，只要你愿意朝著(zhù)正確的解決方案努力。
如果對于你的第一個(gè)補丁的回應只是一些要求你改正的意見(jiàn)，這很正常。這并不意味著(zhù)你的補丁將不會(huì )被接受，這些意見(jiàn)也不是針對你本人的。你要做的只是改正你的補丁然后重新發(fā)送。
內核社區和企業(yè)架構的區別
------------------------
內核社區和大多數傳統的企業(yè)開(kāi)發(fā)環(huán)境工作形式不一樣。這里有一個(gè)列表你可以嘗試遵照執行以避免出現問(wèn)題：
關(guān)于你提交的補丁的好的說(shuō)法： － “這個(gè)可以解決多個(gè)問(wèn)題。”
－ “這個(gè)刪除了2000行代碼。”
－ “這個(gè)補丁解釋了我嘗試想描述的東西。”
－ “我在5個(gè)不同的架構上測試了它……”
－ “這里是一系列的小補丁，它們可以……”
－ “這個(gè)在典型的機器上可以提高表現……”
你應該避免的壞的說(shuō)法： － “我們在A(yíng)IX/ptx/Solaris上都是這樣做的，所以它一定是好的……”
－ “我已經(jīng)這樣做20年了，所以……”
－ “我的公司需要這樣做來(lái)掙錢(qián)”
－ “這是我的一千頁(yè)的設計文檔，它解釋了我的想法”
－ “我已經(jīng)在它上面花了6個(gè)月的心血……”
－ “這里是一個(gè)5000行的補丁，它……”
－ “我重新寫(xiě)了所有現有的垃圾，在這里……”
－ “我有完成期限，這個(gè)補丁必須現在被應用。”
內核社區和大多數傳統軟件工程工作環(huán)境的另一個(gè)不同是沒(méi)有面對面的交流。使用email和irc作為主要交流形式的好處之一是不會(huì )存在基于性別或者種族的歧視。Linux內核工作環(huán)境接受女士和少數民族，因為你的存在只是一個(gè)email地址。國際化也幫助我們實(shí)現了平等的工作環(huán)境，因為你無(wú)法根據一個(gè)人的名字來(lái)判斷一個(gè)人的性別。一個(gè)男人可以叫Andrea，一個(gè)女人可以叫Pat。大多數為L(cháng)inux內核做過(guò)工作或者發(fā)表過(guò)觀(guān)點(diǎn)的女性對此都深有體會(huì )。
對于不習慣英語(yǔ)的人來(lái)說(shuō)語(yǔ)言障礙可能會(huì )導致一些問(wèn)題。對于語(yǔ)言的良好的掌握可以令思想在郵件列表上交流的更暢通，所以建議你在發(fā)送郵件之前檢查一下你的郵件內容在英語(yǔ)里是否有意義。
打散你的補丁
Linux內核社區不樂(lè )意接受大段的代碼，一般會(huì )在收到時(shí)立刻丟棄。你的補丁需要適當的被介紹，討論，并打散為細小的，獨立的片段。這幾乎和公司里經(jīng)常做的完全背道而馳。你的提議必須在開(kāi)發(fā)流程的早期提出，這樣你才可以收到足夠的關(guān)于你的工作的回饋。這也會(huì )令社區感覺(jué)到你是在和他們一起工作，而不是利用他們作為傾倒你的補丁的場(chǎng)所。但是，請不要一次向郵件列表發(fā)送超過(guò)50封email，你的一系列補丁的個(gè)數應該永遠小于這個(gè)數字。
把補丁打散的理由如下：
1) 小的補丁增加了你的補丁被應用的機會(huì )，因為它不需要花太多的時(shí)間和精力來(lái)檢查它的正確性。一個(gè)5行的補丁，一個(gè)維護者只要花一秒鐘瞟一眼然后就可以應用了。不過(guò)，一個(gè)500行的補丁需要一個(gè)小時(shí)來(lái)檢查是否有錯誤（所需的時(shí)間跟補丁的大小差不多成指數級別增長(cháng)）。小補丁也使得在出錯的時(shí)候很容易 debug。如果出了問(wèn)題，小補丁可以一個(gè)一個(gè)的取消，大補丁就比較麻煩了。
2) 除了要把補丁打散之外，在提交之前還要重寫(xiě)和簡(jiǎn)化（或者只是簡(jiǎn)單的重排序）你的補丁。這一點(diǎn)也是很重要的。
這里有一個(gè)內核開(kāi)發(fā)者Al Viro所做的類(lèi)比： “想一下一個(gè)老師為一個(gè)數學(xué)系學(xué)生批改作業(yè)的情景。老師不希望看到學(xué)生在回答出正確答案之前的嘗試和失敗。他們想看到最清楚的，最優(yōu)美的答案。一個(gè)好學(xué)生了解這一點(diǎn)，并不會(huì )在得到最終答案之前把他們的中間結果提交上去。對于內核開(kāi)發(fā)來(lái)說(shuō)同樣是這樣。維護者和評論者不希望看到問(wèn)題的解決方案背后的思考過(guò)程。他們想看到一個(gè)簡(jiǎn)單和優(yōu)美的解決方案。”
提供一個(gè)優(yōu)美的解決方案和同社區一起工作討論你未完成的作品，要維持此二者之間的平衡可能是一個(gè)很有挑戰性的事情。所以應及早的參與一個(gè)開(kāi)發(fā)流程以獲得回饋來(lái)改進(jìn)你的作品，但仍要保證你的補丁的小塊頭，這樣它們可能提早被接受，哪怕是在你的整個(gè)作品還為完成時(shí)。
也請注意，如果你的補丁尚未完成而且還需要修改，請不要提交。
證明你的改動(dòng)
除了打散你的補丁之外，讓Linux社區理解為什么他們要加入這項改動(dòng)也是很重要的。新的功能必須要被證實(shí)它們需要而且有用。
為你的改動(dòng)寫(xiě)文檔
在你提交補丁時(shí)，要格外留心你在email里說(shuō)的話(huà)。這些信息將會(huì )成為這個(gè)補丁的ChangeLog信息，將會(huì )被保留從而使每個(gè)人任何時(shí)候都可以看到。它必須完整的描述這個(gè)補丁，包括：
－ 為什么這個(gè)改動(dòng)是需要的
－ 這個(gè)補丁的整體設計方案
－ 實(shí)現細節
－ 測試結果
欲知這個(gè)過(guò)程到底看起來(lái)是什么樣子的，請看這個(gè)文檔的ChangeLog部分： “The Perfect Patch”
http://www.zip.com.au/~akpm/linux/patches/stuff/tpp.txt所有這些事情有時(shí)候很難做到。要想完美做到這些要求可能需要幾年的時(shí)間。這是一個(gè)持續的發(fā)展過(guò)程，需要很多耐心和決心。但是不要放棄，這是可以實(shí)現的。很多人已經(jīng)做到了這一點(diǎn)，每個(gè)人都經(jīng)歷過(guò)你現在這個(gè)階段。
（責任編輯：
城塵 68476636-8003）
