如何成為一個Linux核心開發者（經典）
分享一下我老師大神的人工智慧教程！零基礎，通俗易懂！http://blog.csdn.net/jiangjunshow
也歡迎大家轉載本篇文章。分享知識，造福人民，實現我們中華民族偉大復興！
這篇文章將是這個話題的最權威的文件。它將教你如何成為一個Linux核心開發者以及學會如何和Linux核心社群一起工作。它不包含任何有關核心程式設計的技術細節，但是會幫你在這方面指明方向。
如果這篇文件裡任何部分已經過時，請把更新資訊以補丁的形式傳送給本文的維護者，他的聯絡方式列在本文件的末尾。
介紹
好了，你想成知道如何成為一個Linux核心開發者麼？或者你的老闆告訴你，“去為這個裝置寫一個Linux驅動。“這篇文件的目的，就是通過描述你需要經歷的過程和提示你如何和社群一起工作，來教給你為達到這些目的所需要知道的所有知識。本文也嘗試解釋社群為什麼這樣工作的一些原因。
核心幾乎全是用C寫成的，有一些架構相關的部分是用匯編語言寫成的。熟練掌握C語言是核心開發的必備條件。組合語言（任何架構）的瞭解不是必須的，除非你準備做某個架構的底層開發。雖然下面這些書不能完全代替紮實的C語言教學和/或者成年累月的經驗，他們還是不錯的參考，如果用得著的話：
- "The C Programming Language"
- "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的補丁傳送給手冊頁的維護者[email protected]。
這裡有一個核心原始碼樹裡需要閱讀的檔案列表：
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
所有這些事情有時候很難做到。要想完美做到這些要求可能需要幾年的時間。這是一個持續的發展過程，需要很多耐心和決心。但是不要放棄，這是可以實現的。很多人已經做到了這一點，每個人都經歷過你現在這個階段。
給我老師的人工智慧教程打call！http://blog.csdn.net/jiangjunshow
