如何成為一個Linux核心開發人員

你想成知道如何成為一個Linux核心開發人員嗎？或者你的老闆告訴你，“去為這個裝置寫一個Linux驅動。“這篇文檔的目的，就是通過描述你需要 經曆的過程和提示你如何和社區一起工作，來教給你為達到這些目的所需要知道的所有知識。本文也嘗試解釋社區為什麼這樣工作的一些原因。
核心幾乎全 是用C寫成的，有一些架構相關的部分是用組合語言寫成的。熟練掌握C語言是核心開發的必備條件。組合語言（任何架構）的瞭解不是必須的，除非你準備做某個 架構的底層開發。雖然下面這些書不能完全代替紮實的C語言教學和/或者成年累月的經驗，他們還是不錯的參考，如果用得著的話：

- "The C Programming Language" 作者: Kernighan and Ritchie [Prentice Hall] - "Practical C Programming" 作者: Steve Oualline [O'Reilly]

核心是用 GNU C 和 GNU 工具鏈寫成的。雖然它符合 ISO C89 標準，它還是使用了一些標準中沒有的擴充。核心是自成體系的 C 環境，它並不依賴標準C庫，所以某些C語言標準是不支援的。任意長度long long類型除法和浮點數是不被允許的。有時候會很難理解核心對於它所使用的工具鏈和擴充的假定，而且不幸的是也沒有關於它們的絕對的參考。請查閱gcc 的info頁(`info gcc`)以擷取有關資訊。
請記住你是在嘗試學習如何與已經存在的開發社區一起工作。這是一群成分複雜的人們，他們對於代碼，風格和步驟有高的標準。這些標準是經過時間檢驗的。
他們發現遵循這些標準對於這樣一個大規模的且地理上分散的團隊是最佳的選擇。嘗試提前學習儘可能多的有關這些標準的知識，因為它們都有很好的文檔；不要期望別人會遵照你或者你公司的行事方式。
法律問題
Linux核心原始碼依照GPL發布。請參考原始碼樹下的COPYING檔案，以擷取有關這個許可證的詳細資料。如果你對這個許可證有疑問，請聯絡你的律師，不要在Linux核心郵件清單裡詢問。郵件清單裡的人們不是律師，你不應該依賴於他們對於法律問題的解釋。
欲瞭解有關GPL的常見問題和答案，請看：
http://www.gnu.org/licenses/gpl-faq.html
文檔
Linux 核心原始碼樹有很多文檔，它們對於學習如何與核心社區交流來說有不可估量的價值。當新的功能加進核心的時候，通常建議作者把解釋這個新功能的文檔也加進內 核。如果一個核心變動導致了核心對使用者空間介面的改變，建議你把這個資訊或者一個解釋了這個變動的manpage的補丁發送給手冊頁的維護者 mtk-manpages@gmx.net。
這裡有一個核心原始碼樹裡需要閱讀的檔案清單：
README
這個檔案簡單介紹了Linux核心的背景，並描述了配置和編譯核心需要做哪些事情。核心新手應該從這裡開始。
Do*****entation/Changes
這個檔案介紹了成功編譯和運行核心所需要各種不同軟體的列表。
Do*****entation/CodingStyle
這個檔案描述了Linux核心代碼風格，還有背後的一些原因。所有的新代碼的要符合這個文檔裡的準則。大多數維護者只會接受符合這些規則的補丁，很多人只看符合正確風格的代碼。
Do*****entation/SubmittingPatches
Do*****entation/SubmittingDrivers
這些檔案非常詳細的介紹了如何成功的建立和發送一個補丁，包括（但不限於）：
－Email內容
－Email格式
－發送給誰
遵守所有這些規則並不能保證成功（對所有的補丁都需要進行內容和風格的詳細檢查），但是不遵守這些規則就一定不會成功。
其他關於如何建立補丁的很好的文章有：
“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
Do*****entation/stable_api_nonsense.txt
這個檔案解釋了有意識的決定－不在核心裡使用穩定的API－的原因，包括：
－子系統分隔層（為了相容？）
－作業系統之間的驅動可移植性
－緩和（或者阻止）核心原始碼樹的急速變動
這個文檔對於瞭解Linux的開發哲學是非常關鍵的，對於由開發其他動作系統轉而開發Linux人也是很重要的。
Do*****entation/SecurityBugs
如果你感覺到你發現了Linux核心裡的一個安全問題，請遵照這個文檔裡所描述的步驟來提醒核心開發人員，並協助解決問題。
Do*****entation/ManagementStyle
這個文檔描述了Linux核心維護者如何運作，以及他們為什麼這樣做。它對於任何核心開發新手（或者任何對本話題感興趣的人）來說是非常重要的。
因為它解釋了一些慣有的錯誤概念，可解決有關核心維護者獨特行為的疑惑。
Do*****entation/stable_kernel_rules.txt
本檔案描述了穩定版本核心釋出的規則，還有如果你想對其中的一個版本做一些改動應該做些什麼。
Do*****entation/kernel-docs.txt
一個有關核心開發的外部文檔的列表。如果你在核心內部文檔裡沒有找到? 要找的東西，你可以參考這個列表。
Do*****entation/applying-patches.txt
介紹了對於什麼是補丁，以及如何應用補丁於不同的核心開發分支。
內 核也有很多可以從原始碼自動產生的文檔。這包括核心內部API的全面描述，有關如何處理好鎖定的規則。這些文檔會被建立於 Do*****entation/DocBook/檔案夾中。在核心主源碼樹中通過運行下面的命令可以建立出PDF，Postscript， HTML和manpage等不同格式的文檔：

make pdfdocs make psdocs make htmldocs make mandocs

成為一個核心開發人員
如果你對Linux核心開發一無所知，你可以看看Linux KernelNewbies項目：
http://kernelnewbies.org
它包含一個郵件清單，在那裡你可以問任何有關核心開發的基礎問題（在問問題之前先搜尋一下存檔，很可能這個問題已經被解答過了。）它還有一個IRC頻道，你可以在裡面即時的提問。它還有很多有用的文檔，對於學習Linux核心開發很有用。
這個網站有有關程式碼群組織，子系統，當前項目（代碼樹之內的和之外的）的基本資料。它也描述了一些基本的“物流”資訊，比如怎麼樣編譯核心和怎麼樣打補丁。
如果你不知道從何處起步，但是你想找一些任務來做以加入核心開發社區，請看一下Linux Kernel Janitor項目：
http://janitor.kernelnewbies.org/
這是一個很好的起步的地方。它描述了一些相對來說簡單的核心中需要清理的和解決的問題。和負責這個項目的開發人員一起工作，你會學到如何令你的補丁進入Linux核心樹的基本知識，而且可能會為你指明下一步的發展方向，如果你自己尚不明確的話。
如果你已經有了一段代碼想要放到核心樹裡，但是需要某種形式的協助，那麼kernel-mentors項目就可以幫你的忙了。這是一個郵件清單，可以在下面找到：
http://selenic.com/mailman/listinfo/kernel-mentors
在 你對Linux核心代碼作任何實際的改動之前，必須要瞭解相關的代碼是如何工作的。為了達到這個目的，沒有比直接讀它（很多困難的地方都有很好的注釋）更 好的方法了，甚至可能是在某個特殊工具的協助下來閱讀。很值得推薦的這樣一種工具是Linux Cross-Reference項目，它可以把原始碼以一種自我引用的、索引的網頁形式顯示出來。一個非常好的最新的核心代碼倉庫可以在這裡找到： http://sosdg.org/~coywolf/lxr
開發流程
Linux核心開發流程當前包括一些主核心分支，和很多不同的子系統專有的核心分支。它們是：

－ 主 2.6.x 核心樹 － 2.6.x.y -stable 核心樹 － 2.6.x -git 核心補丁 － 2.6.x -mm 核心補丁 － 子系統專有核心樹和補丁

2.6.x 核心樹
2.6.x 核心樹是有Linus Torvalds維護的，可以在kernel.org的pub/linux/kernel/v2.6目錄裡找到。它的開發流程是這樣的：
－當一個新的核心發布之後，一個為期兩個星期的視窗開啟，在這段時間裡維護者可以提交大的補丁給Linus，通常是已經在-mm核心中存在了一定時間的補丁。推薦的提交補丁的方式是通過git（有關git的更多資訊可以在http://git.or.cz/找 到），但是普通的補丁也是可以的－兩個星期之後一個-rc1核心發布，然後現在只可以再加入不會為核心添加新功能的補丁，因為那樣的補丁可能會影響這個內 核的穩定性。請注意這個時候一個整的新驅動（或者檔案系統）可以被接受。因為只要這個變動是自成一體的並且不影響它之外的代碼的話，就不會有產生迴歸的危 險。在-rc1發布之後，git可以用來發送補丁給Linus，但是這些補丁也需要發到一個公開的郵件清單裡以備審查。
－ 當Linus確信當前的git（核心代碼管理工具）樹已經處於一個合理的健全狀態，足夠測試時，一個新的-rc就會發布了。目標是每周發布一個新的-rc核心。
－ 這個過程將會持續到核心被認為發行就緒為止，整個流程會持續大概6個星期。
Andrew Morton在linux-kernel郵件清單裡寫的有關核心發布的一句話值得提一下： “沒有人知道什麼時候一個核心會發布，因為它發布的依據已經掌握的bug狀態，而不是事先設想好的一個時間軸。
2.6.x.y -stable 核心樹
有四個數字版本號碼的核心是-stable核心。他們包含一些相對較小的和重要的修正。這些修正針對的是在一個給定2.6.x核心中發現的安全問題或者重大的迴歸。
對於想使用最新的穩定核心並且對於協助測試開發/實驗版本不感興趣的使用者，這是推薦使用的版本。
如果沒有2.6.x.y版本，那麼最高版本號碼的2.6.x核心是當前穩定核心。
2.6.x.y由“stable”團隊維護，每周發布一次。
核心樹裡的檔案Do*****entation/stable_kernel_rules.txt描述了什麼樣的改動可以被-stable樹所接受，以及發布流程是怎樣工作的。
2.6.x -git 補丁
這些是在git倉庫裡管理的Linus核心樹的每日快照。這些補丁每天發布一次，代表Linus樹的目前狀態。它們比-rc核心更具實驗性質，因為它們是自動產生的，以至沒有人曾經瞟上一眼來檢查它們是否處於健全狀態。
2.6.x -mm 核心補丁
　 這些是Andrew Morton發布的實驗性質的核心補丁。Andrew取得所有不同子系統的核心樹和補丁，連同從linux-kernel郵件清單裡拉過來的補丁，把它們 融合在一起。這個樹是新功能和補丁證明自己的場所。如果一個補丁在-mm裡證實了自己的價值，Andrew或者子系統維護者就會把它提交給Linus，以 求被收錄於主線核心中。
強烈建議所有的新補丁在發送給Linus之前都先發到-mm樹裡測試一下。
打了此種補丁的核心不適用於追求穩定的系統中，運行它們比運行其他任何分支都更具冒險性。
如果你想協助核心開發流程，請測試並使用這些核心發布，並在linux-kernel郵件清單裡提供回饋，如果你發現任何問題的話，哪怕什麼問題也沒有。
在所有其他實驗性質的補丁之外，這些核心補丁通常還會包含在發布時在主線-git核心中已經包含的改動。
-mm核心沒有一個固定的發布計劃，但是通常在每兩個-rc核心發布間歇期會發布一些-mm核心（1到3個都很常見）。
子系統專有核心樹和補丁
一些不同的核心子系統開發人員公布他們的開發樹，這樣其他人可以看到在核心的不同領域裡正在發生什麼。這些樹都會被包含在-mm核心發布中。
下面是一些不同的核心樹的列表：

git樹： - Kbuild 開發樹, Sam Ravnborg kernel.org:/pub/scm/linux/kernel/git/sam/kbuild.git - ACPI 開發樹, Len Brown kernel.org:/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6.git - 塊裝置開發樹, Jens Axboe kernel.org:/pub/scm/linux/kernel/git/axboe/linux-2.6-block.git - DRM 開發樹, Dave Airlie kernel.org:/pub/scm/linux/kernel/git/airlied/drm-2.6.git - ia64 開發樹, Tony Luck kernel.org:/pub/scm/linux/kernel/git/aegl/linux-2.6.git - ieee1394 開發樹, 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 - 網路驅動, 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核心樹可以在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核心開發人員追蹤核心bug的地方。我們鼓勵使用者在這個工具中報告他們發現的所有bug。欲知使用核心bugzilla的具體細節，請看：http://test.kernel.org/bugzilla/faq.html
主核心源碼目錄中的REPORTING-BUGS檔案有一個報告可能有的核心bug的模板，並詳細講述了核心開發人員需要什麼樣的資訊，以便他們可追蹤到問題所在。
郵件清單
就像上面的一些文檔所描述的，大多數核心核心開發人員參與Linux核心郵件清單的討論。如何訂閱和取消訂閱這個列表的細節可以從這裡找到：
http://vger.kernel.org/vger-lists.html#linux-kernel
網上很多地方都有這個郵件清單的存檔。使用一個搜尋引擎來搜尋這些存檔。比如：
http://dir.gmane.org/gmane.linux.kernel
強烈建議你在向列表發郵件詢問之前，先在存檔中搜尋一下你想問的話題。很多事情都已經詳細的討論過了，它們只在郵件清單存檔中有記錄。
很多核心子系統也有它們單獨的郵件清單，在那裡開發人員們做他們的開發工作。請查看MAINTAINER檔案來找到這些不同子系統的郵件清單。
很多郵件清單放置於kernel.org之上。有關它們的資訊可以在這裡找到：
http://vger.kernel.org/vger-lists.html
請記住在使用這些列表時請遵守良好的行為習慣。下面的URL有一些如何在郵件清單上與人交流的簡單的準則，雖然有一點俗氣：http://www.albion.com/netiquette
如果有許多人回複你的郵件，收件者的抄送列表會變得很長。在沒有一個合理的理由時不要把任何人從抄送列表中去掉，或者不要只回複被列出的地址。要對於收到同一封信兩次感到習慣，一次從發信者，一次從郵件清單。不要為了好看而加上別緻的郵件標頭部，人們不喜歡這樣。
記得保證你的回複的上下文和屬性的完整性，在你的回複的最上方保留類似 “John Kernelhacker wrote ...“的字樣，把你的回複寫在被引用的段落之間，而不要寫在郵件的最上方。
如果你在你的郵件裡加入了補丁，要確保它們是純文字，就象Do*****entation/SubmittingPatches裡所說的。核心開發人員不希望處理附件或者壓縮的補丁；他們會希望評價你的補丁的每一行，只有純文字才符合這個要求。
確保你使用的郵件用戶端軟體不會破壞空格和定位字元。你可以發一個郵件給你自己，然後應用你自己的補丁來先做個測試。如果不行，修複你的郵件程式或者換一個。
最重要的一點，請記得顯示出你對其他訂閱者的尊重。
和社區一起工作
核心社區的目標是提供可能提供的最好的核心。當你提交了一個補丁等待被收錄時，它會被且僅被該領域的技術權威所檢查。所以，你應該期待什麼呢？
－ 批評
－ 評論
－ 被要求改動
－ 被要求解釋
－ 沉默
記 住，這是讓你的補丁進入核心的一部分。你必須能夠接受對你的補丁的批評和評論，在技術的層面上評估它，然後要麼對你的補丁作出修改，要麼提供清晰而言簡意 賅的理由解釋為什麼不應該做改動。如果沒有對你的補丁的回複，等幾天再試一次，有時候在流量很大的時候信件可能丟失，或被人忽略遺忘了。
你不應該做什麼：

－ 期待你的補丁沒有任何疑問的被接受 － 不接受批評，不承認缺點 － 忽略評論 － 在不做任何修改的情況下再次提交補丁

在一個尋找可能存在的最好的技術解決方案的社區裡，關於一個補丁怎樣的有用必定會存在不同的意見。你應該採取合作的態度，願意改變你的意見以適應核心的需要。或者至少願意證明的你的觀點有價值。記住，犯錯誤是可以接受的，只要你願意朝著正確的解決方案努力。
如果對於你的第一個補丁的回應只是一些要求你改正的意見，這很正常。這並不意味著你的補丁將不會被接受，這些意見也不是針對你本人的。你要做的只是改正你的補丁然後重新發送。
核心社區和企業架構的區別
------------------------
核心社區和大多數傳統的企業開發環境工作形式不一樣。這裡有一個列表你可以嘗試遵照執行以避免出現問題：
關於你提交的補丁的好的說法：

－ “這個可以解決多個問題。” － “這個刪除了2000行代碼。” － “這個補丁解釋了我嘗試想描述的東西。” － “我在5個不同的架構上測試了它……” － “這裡是一系列的小補丁，它們可以……” － “這個在典型的機器上可以提高表現……”

你應該避免的壞的說法：

－ “我們在AIX/ptx/Solaris上都是這樣做的，所以它一定是好的……” － “我已經這樣做20年了，所以……” － “我的公司需要這樣做來掙錢” － “這是我的一千頁的設計文檔，它解釋了我的想法” － “我已經在它上面花了6個月的心血……” － “這裡是一個5000行的補丁，它……” － “我重新寫了所有現有的垃圾，在這裡……” － “我有完成期限，這個補丁必須現在被應用。”

核心社區和大多數傳統軟體工程工作環境的另一個不同是沒有面對面的交流。使用email和irc作為主要交流形式的好處之一是不會存在基於性別或者種族的 歧視。Linux核心工作環境接受女士和少數民族，因為你的存在只是一個email地址。國際化也協助我們實現了平等的工作環境，因為你無法根據一個人的 名字來判斷一個人的性別。一個男人可以叫Andrea，一個女人可以叫Pat。大多數為Linux核心做過工作或者發表過觀點的女性對此都深有體會。
對於不習慣英語的人來說語言障礙可能會導致一些問題。對於語言的良好的掌握可以令思想在郵件清單上交流的更暢通，所以建議你在發送郵件之前檢查一下你的郵件內容在英語裡是否有意義。
打散你的補丁
Linux 核心社區不樂意接受大段的代碼，一般會在收到時立刻丟棄。你的補丁需要適當的被介紹，討論，並打散為細小的，獨立的片段。這幾乎和公司裡經常做的完全背道 而馳。你的提議必須在開發流程的早期提出，這樣你才可以收到足夠的關於你的工作的回饋。這也會令社區感覺到你是在和他們一起工作，而不是利用他們作為傾倒 你的補丁的場所。但是，請不要一次向郵件清單發送超過50封email，你的一系列補丁的個數應該永遠小於這個數字。
把補丁打散的理由如下：
1) 小的補丁增加了你的補丁被應用的機會，因為它不需要花太多的時間和精力來檢查它的正確性。一個5行的補丁，一個維護者只要花一秒鐘瞟一眼然後就可以應用 了。不過，一個500行的補丁需要一個小時來檢查是否有錯誤（所需的時間跟補丁的大小差不多成指數層級增長）。小補丁也使得在出錯的時候很容易 debug。如果出了問題，小補丁可以一個一個的取消，大補丁就比較麻煩了。
2) 除了要把補丁打散之外，在提交之前還要重寫和簡化（或者只是簡單的重排序）你的補丁。這一點也是很重要的。
這 裡有一個核心開發人員Al Viro所做的類比： “想一下一個老師為一個數學系學生批改作業的情景。老師不希望看到學生在回答出正確答案之前的嘗試和失敗。他們想看到最清楚的，最優美的答案。一個好學生 瞭解這一點，並不會在得到最終答案之前把他們的中間結果提交上去。對於核心開發來說同樣是這樣。維護者和評論者不希望看到問題的解決方案背後的思考過程。 他們想看到一個簡單和優美的解決方案。”
提供一個優美的解決方案和同社區一起工作討論你未完成的作品，要維持此二者之間的平衡可能是一個很有挑戰性的事情。所以應及早的參與一個開發流程以獲得回饋來改進你的作品，但仍要保證你的補丁的小塊頭，這樣它們可能提早被接受，哪怕是在你的整個作品還為完成時。
也請注意，如果你的補丁尚未完成而且還需要修改，請不要提交。
證明你的改動
除了打散你的補丁之外，讓Linux社區理解為什麼他們要加入這項改動也是很重要的。新的功能必須要被證實它們需要而且有用。
為你的改動寫文檔
在你提交補丁時，要格外留心你在email裡說的話。這些資訊將會成為這個補丁的ChangeLog資訊，將會被保留從而使每個人任何時候都可以看到。它必須完整的描述這個補丁，包括：

－ 為什麼這個改動是需要的 － 這個補丁的整體設計方案 － 實現細節 － 測試結果

欲知這個過程到底看起來是什麼樣子的，請看這個文檔的ChangeLog部分： “The Perfect Patch”
http://www.zip.com.au/~akpm/linux/patches/stuff/tpp.txt
所有這些事情有時候很難做到。要想完美做到這些要求可能需要幾年的時間。這是一個持續的發展過程，需要很多耐心和決心。但是不要放棄，這是可以實現的。很多人已經做到了這一點，每個人都經曆過你現在這個階段。