---------------------
這是壹篇將如何參與Linux內核開發的相關問題壹網打盡的終極秘笈。它將指導妳
成為壹名Linux內核開發者，並且學會如何同Linux內核開發社區合作。它盡可能不
包括任何關於內核編程的技術細節，但會給妳指引壹條獲得這些知識的正確途徑。
如果這篇文章中的任何內容不再適用，請給文末列出的文件維護者發送補丁。
入門
----
妳想了解如何成為壹名Linux內核開發者？或者老板吩咐妳“給這個設備寫個Linux
驅動程序”？這篇文章的目的就是教會妳達成這些目標的全部訣竅，它將描述妳需
要經過的流程以及給出如何同內核社區合作的壹些提示。它還將試圖解釋內核社區
為何這樣運作。
Linux內核大部分是由C語言寫成的，壹些體系結構相關的代碼用到了匯編語言。要
參與內核開發，妳必須精通C語言。除非妳想為某個架構開發底層代碼，否則妳並
不需要了解（任何體系結構的）匯編語言。下面列舉的書籍雖然不能替代紮實的C
語言教育和多年的開發經驗，但如果需要的話，做為參考還是不錯的：
- "The C Programming Language" by Kernighan and Ritchie [Prentice Hall]
《C程序設計語言（第2版·新版）》（徐寶文 李誌 譯）[機械工業出版社]
- "Practical C Programming" by Steve Oualline [O'Reilly]
《實用C語言編程（第三版）》（郭大海 譯）[中國電力出版社]
- "C: A Reference Manual" by Harbison and Steele [Prentice Hall]
《C語言參考手冊（原書第5版）》（邱仲潘 等譯）[機械工業出版社]
Linux內核使用GNU C和GNU工具鏈開發。雖然它遵循ISO C89標準，但也用到了壹些
標準中沒有定義的擴展。內核是自給自足的C環境，不依賴於標準C庫的支持，所以
並不支持C標準中的部分定義。比如long long類型的大數除法和浮點運算就不允許
使用。有時候確實很難弄清楚內核對工具鏈的要求和它所使用的擴展，不幸的是目
前還沒有明確的參考資料可以解釋它們。請查閱gcc信息頁（使用“info gcc”命令
顯示）獲得壹些這方面信息。
請記住妳是在學習怎麽和已經存在的開發社區打交道。它由壹群形形色色的人組成，
他們對代碼、風格和過程有著很高的標準。這些標準是在長期實踐中總結出來的，
適應於地理上分散的大型開發團隊。它們已經被很好得整理成檔，建議妳在開發
之前盡可能多的學習這些標準，而不要期望別人來適應妳或者妳公司的行為方式。
法律問題
--------
Linux內核源代碼都是在GPL（通用公***許可證）的保護下發布的。要了解這種許可
的細節請查看源代碼主目錄下的COPYING文件。如果妳對它還有更深入問題請聯系
律師，而不要在Linux內核郵件組上提問。因為郵件組裏的人並不是律師，不要期
望他們的話有法律效力。
對於GPL的常見問題和解答，請訪問以下鏈接：
，以向手冊頁(manpages)
的維護者解釋這些變化。
以下是內核代碼中需要閱讀的文檔：
README
文件簡要介紹了Linux內核的背景，並且描述了如何配置和編譯內核。內核的
新用戶應該從這裏開始。
Documentation/Changes
文件給出了用來編譯和使用內核所需要的最小軟件包列表。
Documentation/CodingStyle
描述Linux內核的代碼風格和理由。所有新代碼需要遵守這篇文檔中定義的規
範。大多數維護者只會接收符合規定的補丁，很多人也只會幫忙檢查符合風格
的代碼。
Documentation/SubmittingPatches
Documentation/SubmittingDrivers
這兩份文檔明確描述如何創建和發送補丁，其中包括（但不僅限於)：
- 郵件內容
- 郵件格式
- 選擇收件人
遵守這些規定並不能保證提交成功（因為所有補丁需要通過嚴格的內容和風格
審查），但是忽視他們幾乎就意味著失敗。
其他關於如何正確地生成補丁的優秀文檔包括：
"The Perfect Patch"
/mailman/listinfo/kernel-mentors
在真正動手修改內核代碼之前，理解要修改的代碼如何運作是必需的。要達到這個
目的，沒什麽辦法比直接讀代碼更有效了（大多數花招都會有相應的註釋），而且
壹些特制的工具還可以提供幫助。例如，“Linux代碼交叉引用”項目就是壹個值得
特別推薦的幫助工具，它將源代碼顯示在有編目和索引的網頁上。其中壹個更新及
時的內核源碼庫，可以通過以下地址訪問：
>
git.kernel.org:/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6.git
- 塊設備開發源碼樹, Jens Axboe <axboe@suse.de>
git.kernel.org:/pub/scm/linux/kernel/git/axboe/linux-2.6-block.git
- DRM開發源碼樹, Dave Airlie <airlied@linux.ie>
git.kernel.org:/pub/scm/linux/kernel/git/airlied/drm-2.6.git
- ia64開發源碼樹, Tony Luck <tony.luck@intel.com>
git.kernel.org:/pub/scm/linux/kernel/git/aegl/linux-2.6.git
- ieee1394開發源碼樹, Jody McIntyre <scjody@modernduck.com>
git.kernel.org:/pub/scm/linux/kernel/git/scjody/ieee1394.git
- infiniband開發源碼樹, Roland Dreier <rolandd@cisco.com>
git.kernel.org:/pub/scm/linux/kernel/git/roland/infiniband.git
- libata開發源碼樹, Jeff Garzik <jgarzik@pobox.com>
git.kernel.org:/pub/scm/linux/kernel/git/jgarzik/libata-dev.git
- 網絡驅動程序開發源碼樹, Jeff Garzik <jgarzik@pobox.com>
git.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git
- pcmcia開發源碼樹, Dominik Brodowski <linux@dominikbrodowski.net>
git.kernel.org:/pub/scm/linux/kernel/git/brodo/pcmcia-2.6.git
- SCSI開發源碼樹, James Bottomley <James.Bottomley@SteelEye.com>
git.kernel.org:/pub/scm/linux/kernel/git/jejb/scsi-misc-2.6.git
使用quilt管理的補丁集：
- USB, PCI, 驅動程序核心和I2C, Greg Kroah-Hartman <gregkh@suse.de>
kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/
- x86-64, 部分i386, Andi Kleen <ak@suse.de>
ftp.firstfloor.org:/pub/ak/x86_64/quilt/
其他內核源碼樹可以在/netiquette/
當有很多人回復妳的郵件時，郵件的抄送列表會變得很長。請不要將任何人從抄送
列表中刪除，除非妳有足夠的理由這麽做。也不要只回復到郵件列表。請習慣於同
壹封郵件接收兩次（壹封來自發送者壹封來自郵件列表），而不要試圖通過添加壹
些奇特的郵件頭來解決這個問題，人們不會喜歡的。
記住保留妳所回復內容的上下文和源頭。在妳回復郵件的頂部保留“某某某說到……”
這幾行。將妳的評論加在被引用的段落之間而不要放在郵件的頂部。
如果妳在郵件中附帶補丁，請確認它們是可以直接閱讀的純文本（如
Documentation/SubmittingPatches文檔中所述）。內核開發者們不希望遇到附件
或者被壓縮了的補丁。只有這樣才能保證他們可以直接評論妳的每行代碼。請確保
妳使用的郵件發送程序不會修改空格和制表符。壹個防範性的測試方法是先將郵件
發送給自己，然後自己嘗試是否可以順利地打上收到的補丁。如果測試不成功，請
調整或者更換妳的郵件發送程序直到它正確工作為止。
總而言之，請尊重其他的郵件列表訂閱者。