亚洲av成人无遮挡网站在线观看,少妇性bbb搡bbb爽爽爽,亚洲av日韩精品久久久久久,兔费看少妇性l交大片免费,无码少妇一区二区三区

Chinaunix

標題: HOWTO do Linux kernel development - take 3 (中文版，轉(zhuǎn)自CLF，譯者：zhllg) [打印本頁]
作者: leviathan.alan    時間: 2006-06-20 09:21
標題: HOWTO do Linux kernel development - take 3 (中文版，轉(zhuǎn)自CLF，譯者：zhllg)
譯者：張樂 robert_AT_thizlinux_DOT_com
原作：Greg KH
譯注：本文依據(jù)take 3翻譯，應該不會再有大的改動了，如果有本文會隨時更新
時間倉促，恐難免錯漏，歡迎指正
原文：http://permalink.gmane.org/gmane.linux.kernel/349656 (轉(zhuǎn)貼說明：也可以在內(nèi)核源代碼目錄下的Documentation/HOWTO找到本文英文版)
譯文：

------------------------------

HOWTO do Linux kernel development
---------------------------------

這篇文章將是這個話題的最權威的文檔。它將教你如何成為一個Linux內(nèi)核開發(fā)者以及學會如何和Linux內(nèi)核社區(qū)一起工作。它不包含任何有關內(nèi)核編程的技術細節(jié)，但是會幫你在這方面指明方向。

如果這篇文檔里任何部分已經(jīng)過時，請把補丁發(fā)送給本文的維護者，他的聯(lián)系方式列在本文檔的末尾。

介紹
---

好了，你想成知道如何成為一個Linux內(nèi)核開發(fā)者么？或者你的老板告訴你，“去為這個設備寫一個Linux驅(qū)動。“這篇文檔的目的，就是通過描述你需要經(jīng)歷的過程和提示你如何和社區(qū)一起工作，來教給你為達到這些目的所需要知道的所有知識。本文也嘗試解釋社區(qū)為什么這樣工作的一些原因。

內(nèi)核幾乎全是用C寫成的，有一些架構相關的部分是用匯編語言寫成的。熟練掌握C語言是內(nèi)核開發(fā)的必備條件。匯編語言（任何架構）的了解不是必須的，除非你準備做某個架構的底層開發(fā)。雖然下面這些書不能完全代替扎實的C語言教學和/或者成年累月的經(jīng)驗，他們還是不錯的參考，如果用得著的話：
- "The C Programming Language" 作者： Kernighan and Ritchie [Prentice Hall]
- "Practical C Programming" 作者： Steve Oualline [O'Reilly]


內(nèi)核是用 GNU C 和 GNU 工具鏈寫成的。雖然它符合 ISO C89 標準，它還是使用了一些標準中沒有的擴展。內(nèi)核是自稱體系的 C 環(huán)境，它并不依賴標準C庫，所以某些C語言標準是不支持的。任意長度long long類型除法和浮點數(shù)是不被允許的。有時候會很難理解內(nèi)核對于它所使用的工具鏈和擴展的假定，而且不幸的是也沒有關于它們的絕對的參考。請查閱gcc 的info頁(`info gcc`)以獲取有關信息。

請記住你是在嘗試學習如何與已經(jīng)存在的開發(fā)社區(qū)一起工作。這是一群成分復雜的人們，他們對于代碼，風格和步驟有高的標準。這些標準是經(jīng)過時間檢驗的。他們發(fā)現(xiàn)遵循這些標準對于這樣一個大規(guī)模的且地理上分散的團隊是最佳的選擇。嘗試提前學習盡可能多的有關這些標準的知識，因為它們都有很好的文檔；不要期望別人會遵照你或者你公司的行事方式。

法律問題
------

Linux內(nèi)核源代碼依照GPL發(fā)布。請參考源代碼樹下的COPYING文件，以獲取有關這個許可證的詳細信息。如果你對這個許可證有疑問，請聯(lián)系你的律師，不要在Linux內(nèi)核郵件列表里詢問。郵件列表里的人們不是律師，你不應該依賴于他們對于法律問題的解釋。

欲了解有關GPL的常見問題和答案，請看：
http://www.gnu.org/licenses/gpl-faq.html

文檔
---

Linux內(nèi)核源代碼樹有很多文檔，它們對于學習如何與內(nèi)核社區(qū)交流來說有不可估量的價值。當新的功能加進內(nèi)核的時候，通常建議作者把解釋這個新功能的文檔也加進內(nèi)核。如果一個內(nèi)核變動導致了內(nèi)核對用戶空間界面的改變，建議你把這個信息或者一個解釋了這個變動的manpage的補丁發(fā)送給手冊頁的維護者 mtk-manpages@gmx.net。

這里有一個內(nèi)核源代碼樹里需要閱讀的文件列表：
README
這個文件簡單介紹了Linux內(nèi)核的背景，并描述了配置和編譯內(nèi)核需要做哪些事情。內(nèi)核新手應該從這里開始。

Documentation/Changes
這個文件介紹了成功編譯和運行內(nèi)核所需要各種不同軟件的列表。

Documentation/CodingStyle
這個文件描述了Linux內(nèi)核代碼風格，還有背后的一些原因。所有的新代碼的要符合這個文檔里的準則。大多數(shù)維護者只會接受符合這些規(guī)則的補丁，很多人只看符合正確風格的代碼。

Documentation/SubmittingPatches
Documentation/SubmittingDrivers
這些文件非常詳細的介紹了如何成功的創(chuàng)建和發(fā)送一個補丁，包括（但不限于）：
－Email內(nèi)容
－Email格式
－發(fā)送給誰
遵守所有這些規(guī)則并不能保證成功（對所有的補丁都需要進行內(nèi)容和風格的詳細檢查），但是不遵守這些規(guī)則就一定不會成功。

其他關于如何創(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.html

Documentation/stable_api_nonsense.txt
這個文件解釋了有意識的決定－不在內(nèi)核里使用穩(wěn)定的API－的原因，包括：
－子系統(tǒng)分隔層（為了兼容？）
－操作系統(tǒng)之間的驅(qū)動可移植性
－緩和（或者阻止）內(nèi)核源代碼樹的急速變動
這個文檔對于了解Linux的開發(fā)哲學是非常關鍵的，對于由開發(fā)其他操作系統(tǒng)轉(zhuǎn)而開發(fā)Linux人也是很重要的。

Documentation/SecurityBugs
如果你感覺到你發(fā)現(xiàn)了Linux內(nèi)核里的一個安全問題，請遵照這個文檔里所描述的步驟來提醒內(nèi)核開發(fā)者，并幫助解決問題。

Documentation/ManagementStyle
這個文檔描述了Linux內(nèi)核維護者如何運作，以及他們?yōu)槭裁催@樣做。它對于任何內(nèi)核開發(fā)新手（或者任何對本話題感興趣的人）來說是非常重要的。因為它解釋了一些慣有的錯誤概念，可解決有關內(nèi)核維護者獨特行為的疑惑。

Documentation/stable_kernel_rules.txt
本文件描述了穩(wěn)定版本內(nèi)核釋出的規(guī)則，還有如果你想對其中的一個版本做一些改動應該做些什么。

Documentation/kernel-docs.txt
一個有關內(nèi)核開發(fā)的外部文檔的列表。如果你在內(nèi)核內(nèi)部文檔里沒有找到你要找的東西，你可以參考這個列表。

Documentation/applying-patches.txt
介紹了對于什么是補丁，以及如何應用補丁于不同的內(nèi)核開發(fā)分支。

內(nèi)核也有很多可以從源代碼自動產(chǎn)生的文檔。這包括內(nèi)核內(nèi)部API的全面描述，有關如何處理好鎖定的規(guī)則。這些文檔會被創(chuàng)建于 Documentation/DocBook/文件夾中。在內(nèi)核主源碼樹中通過運行下面的命令可以創(chuàng)建出PDF，Postscript，HTML和 manpage等不同格式的文檔：
make pdfdocs
make psdocs
make htmldocs
make mandocs

成為一個內(nèi)核開發(fā)者
--------------

如果你對Linux內(nèi)核開發(fā)一無所知，你可以看看Linux KernelNewbies項目：
http://kernelnewbies.org
它包含一個郵件列表，在那里你可以問任何有關內(nèi)核開發(fā)的基礎問題（在問問題之前先搜索一下存檔，很可能這個問題已經(jīng)被解答過了。）它還有一個IRC頻道，你可以在里面實時的提問。它還有很多有用的文檔，對于學習Linux內(nèi)核開發(fā)很有用。

這個網(wǎng)站有有關代碼組織，子系統(tǒng)，當前項目（代碼樹之內(nèi)的和之外的）的基本信息。它也描述了一些基本的“物流”信息，比如怎么樣編譯內(nèi)核和怎么樣打補丁。

如果你不知道從何處起步，但是你想找一些任務來做以加入內(nèi)核開發(fā)社區(qū)，請看一下Linux Kernel Janitor項目：
http://janitor.kernelnewbies.org/
這是一個很好的起步的地方。它描述了一些相對來說簡單的內(nèi)核中需要清理的和解決的問題。和負責這個項目的開發(fā)者一起工作，你會學到如何令你的補丁進入Linux內(nèi)核樹的基本知識，而且可能會為你指明下一步的發(fā)展方向，如果你自己尚不明確的話。

如果你已經(jīng)有了一段代碼想要放到內(nèi)核樹里，但是需要某種形式的幫助，那么kernel-mentors項目就可以幫你的忙了。這是一個郵件列表，可以在下面找到：
http://selenic.com/mailman/listinfo/kernel-mentors

在你對Linux內(nèi)核代碼作任何實際的改動之前，必須要了解相關的代碼是如何工作的。為了達到這個目的，沒有比直接讀它（很多困難的地方都有很好的注釋）更好的方法了，甚至可能是在某個特殊工具的幫助下來閱讀。很值得推薦的這樣一種工具是Linux Cross-Reference項目，它可以把源代碼以一種自我引用的、索引的網(wǎng)頁形式顯示出來。一個非常好的最新的內(nèi)核代碼倉庫可以在這里找到：
http://sosdg.org/~coywolf/lxr

開發(fā)流程
------

Linux內(nèi)核開發(fā)流程當前包括一些主內(nèi)核分支，和很多不同的子系統(tǒng)專有的內(nèi)核分支。它們是：
－ 主 2.6.x 內(nèi)核樹
－ 2.6.x.y -stable 內(nèi)核樹
－ 2.6.x -git 內(nèi)核補丁
－ 2.6.x -mm 內(nèi)核補丁
－ 子系統(tǒng)專有內(nèi)核樹和補丁

2.6.x 內(nèi)核樹
-----------
2.6.x 內(nèi)核樹是有Linus Torvalds維護的，可以在kernel.org的pub/linux/kernel/v2.6目錄里找到。它的開發(fā)流程是這樣的：
－當一個新的內(nèi)核發(fā)布之后，一個為期兩個星期的窗口打開，在這段時間里維護者可以提交大的補丁給Linus，通常是已經(jīng)在-mm內(nèi)核中存在了一定時間的補丁。推薦的提交補丁的方式是通過git（有關git的更多信息可以在http://git.or.cz/找到），但是普通的補丁也是可以的
－兩個星期之后一個-rc1內(nèi)核發(fā)布，然后現(xiàn)在只可以再加入不會為內(nèi)核添加新功能的補丁，因為那樣的補丁可能會影響這個內(nèi)核的穩(wěn)定性。請注意這個時候一個整的新驅(qū)動（或者文件系統(tǒng)）可以被接受。因為只要這個變動是自成一體的并且不影響它之外的代碼的話，就不會有產(chǎn)生回歸的危險。在-rc1發(fā)布之后，git可以用來發(fā)送補丁給Linus，但是這些補丁也需要發(fā)到一個公開的郵件列表里以備審查。
－ 當Linus確信當前的git（內(nèi)核代碼管理工具）樹已經(jīng)處于一個合理的健全狀態(tài)，足夠測試時，一個新的-rc就會發(fā)布了。目標是每周發(fā)布一個新的-rc內(nèi)核。
－ 這個過程將會持續(xù)到內(nèi)核被認為可以發(fā)布為止，整個流程會持續(xù)大概6個星期。

Andrew Morton在linux-kernel郵件列表里寫的有關內(nèi)核發(fā)布的一句話值得提一下：
“沒有人知道什么時候一個內(nèi)核會發(fā)布，因為它發(fā)布的依據(jù)已經(jīng)掌握的bug狀態(tài)，而不是事先設想好的一個時間線�！�

2.6.x.y -stable 內(nèi)核樹
---------------------

有四個數(shù)字版本號的內(nèi)核是-stable內(nèi)核。他們包含一些相對較小的和重要的修正。這些修正針對的是在一個給定2.6.x內(nèi)核中發(fā)現(xiàn)的安全問題或者重大的回歸。

對于想使用最新的穩(wěn)定內(nèi)核并且對于幫助測試開發(fā)/實驗版本不感興趣的用戶，這是推薦使用的版本。

如果沒有2.6.x.y版本，那么最高版本號的2.6.x內(nèi)核是當前穩(wěn)定內(nèi)核。

2.6.x.y由“stable”團隊<stable@kernel.org>維護，每周發(fā)布一次。

內(nèi)核樹里的文件Documentation/stable_kernel_rules.txt描述了什么樣的改動可以被-stable樹所接受，以及發(fā)布流程是怎樣工作的。

2.6.x -git 補丁
--------------
這些是在git倉庫里管理的Linus內(nèi)核樹的每日快照。這些補丁每天發(fā)布一次，代表Linus樹的當前狀態(tài)。它們比-rc內(nèi)核更具實驗性質(zhì)，因為它們是自動生成的，以至沒有人曾經(jīng)瞟上一眼來檢查它們是否處于健全狀態(tài)。

2.6.x -mm 內(nèi)核補丁
----------------
這些是Andrew Morton發(fā)布的實驗性質(zhì)的內(nèi)核補丁。Andrew取得所有不同子系統(tǒng)的內(nèi)核樹和補丁，連同從linux-kernel郵件列表里拉過來的補丁，把它們?nèi)诤显谝黄�。這個樹是新功能和補丁證明自己的場所。如果一個補丁在-mm里證實了自己的價值，Andrew或者子系統(tǒng)維護者就會把它提交給Linus，以求被收錄于主線內(nèi)核中。

強烈建議所有的新補丁在發(fā)送給Linus之前都先發(fā)到-mm樹里測試一下。

打了此種補丁的內(nèi)核不適用于追求穩(wěn)定的系統(tǒng)中，運行它們比運行其他任何分支都更具冒險性。

如果你想幫助內(nèi)核開發(fā)流程，請測試并使用這些內(nèi)核發(fā)布，并在linux-kernel郵件列表里提供回饋，如果你發(fā)現(xiàn)任何問題的話，哪怕什么問題也沒有。

在所有其他實驗性質(zhì)的補丁之外，這些內(nèi)核補丁通常還會包含在發(fā)布時在主線-git內(nèi)核中已經(jīng)包含的改動。

-mm內(nèi)核沒有一個固定的發(fā)布計劃，但是通常在每兩個-rc內(nèi)核發(fā)布間歇期會發(fā)布一些-mm內(nèi)核（1到3個都很常見）。

子系統(tǒng)專有內(nèi)核樹和補丁
-----------------
一些不同的內(nèi)核子系統(tǒng)開發(fā)者公布他們的開發(fā)樹，這樣其他人可以看到在內(nèi)核的不同領域里正在發(fā)生什么。這些樹都會被包含在-mm內(nèi)核發(fā)布中。

下面是一些不同的內(nèi)核樹的列表：
git樹：
- Kbuild 開發(fā)樹, Sam Ravnborg <sam@ravnborg.org>
kernel.org:/pub/scm/linux/kernel/git/sam/kbuild.git

- ACPI 開發(fā)樹, Len Brown <len.brown@intel.com>
kernel.org:/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6.git

- 塊設備開發(fā)樹, Jens Axboe <axboe@suse.de>
kernel.org:/pub/scm/linux/kernel/git/axboe/linux-2.6-block.git

- DRM 開發(fā)樹, Dave Airlie <airlied@linux.ie>
kernel.org:/pub/scm/linux/kernel/git/airlied/drm-2.6.git

- ia64 開發(fā)樹, Tony Luck <tony.luck@intel.com>
kernel.org:/pub/scm/linux/kernel/git/aegl/linux-2.6.git

- ieee1394 開發(fā)樹, Jody McIntyre <scjody@modernduck.com>
kernel.org:/pub/scm/linux/kernel/git/scjody/ieee1394.git

- infiniband, Roland Dreier <rolandd@cisco.com>
kernel.org:/pub/scm/linux/kernel/git/roland/infiniband.git

- libata, Jeff Garzik <jgarzik@pobox.com>
kernel.org:/pub/scm/linux/kernel/git/jgarzik/libata-dev.git

- 網(wǎng)絡驅(qū)動, Jeff Garzik <jgarzik@pobox.com>
kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git

- pcmcia, Dominik Brodowski <linux@dominikbrodowski.net>
kernel.org:/pub/scm/linux/kernel/git/brodo/pcmcia-2.6.git

- SCSI, James Bottomley <James.Bottomley@SteelEye.com>
kernel.org:/pub/scm/linux/kernel/git/jejb/scsi-misc-2.6.git

其他git內(nèi)核樹可以在http://kernel.org/git找到

quilt trees:
- USB, PCI, Driver Core, and I2C, Greg Kroah-Hartman <gregkh@suse.de>
kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/

報告Bug
------

bugzilla.kernel.org是Linux內(nèi)核開發(fā)者追蹤內(nèi)核bug的地方。我們鼓勵用戶在這個工具中報告他們發(fā)現(xiàn)的所有bug。欲知使用內(nèi)核bugzilla的具體細節(jié)，請看：
http://test.kernel.org/bugzilla/faq.html

主內(nèi)核源碼目錄中的REPORTING-BUGS文件有一個報告可能有的內(nèi)核bug的模板，并詳細講述了內(nèi)核開發(fā)者需要什么樣的信息，以便他們可追蹤到問題所在。

郵件列表
------

就像上面的一些文檔所描述的，大多數(shù)核心內(nèi)核開發(fā)者參與Linux內(nèi)核郵件列表的討論。如何訂閱和取消訂閱這個列表的細節(jié)可以從這里找到：
http://vger.kernel.org/vger-lists.html#linux-kernel
網(wǎng)上很多地方都有這個郵件列表的存檔。使用一個搜索引擎來搜索這些存檔。比如：
http://dir.gmane.org/gmane.linux.kernel
強烈建議你在向列表發(fā)郵件詢問之前，先在存檔中搜索一下你想問的話題。很多事情都已經(jīng)詳細的討論過了，它們只在郵件列表存檔中有記錄。

很多內(nèi)核子系統(tǒng)也有它們單獨的郵件列表，在那里開發(fā)者們做他們的開發(fā)工作。請查看MAINTAINER文件來找到這些不同子系統(tǒng)的郵件列表。

很多郵件列表放置于kernel.org之上。有關它們的信息可以在這里找到：
http://vger.kernel.org/vger-lists.html

請記住在使用這些列表時請遵守良好的行為習慣。下面的URL有一些如何在郵件列表上與人交流的簡單的準則，雖然有一點俗氣：
http://www.albion.com/netiquette

如果有許多人回復你的郵件，收件人的抄送列表會變得很長。在沒有一個合理的理由時不要把任何人從抄送列表中去掉，或者不要只回復被列出的地址。要對于收到同一封信兩次感到習慣，一次從發(fā)信者，一次從郵件列表。不要為了好看而加上別致的郵件頭部，人們不喜歡這樣。

記得保證你的回復的上下文和屬性的完整性，在你的回復的最上方保留類似“John Kernelhacker wrote ...“的字樣，把你的回復寫在被引用的段落之間，而不要寫在郵件的最上方。

如果你在你的郵件里加入了補丁，要確保它們是純文本，就想Documentation/SubmittingPatches里所說的。內(nèi)核開發(fā)者不希望處理附件或者壓縮的補丁；他們會希望評價你的補丁的每一行，只有純文本才符合這個要求。確保你使用的郵件客戶端軟件不會破壞空格和制表符。你可以發(fā)一個郵件給你自己，然后應用你自己的補丁來先做個測試。如果不行，修復你的郵件程序或者換一個。

最重要的一點，請記得顯示出你對其他訂閱者的尊重。

和社區(qū)一起工作
-----------

內(nèi)核社區(qū)的目標是提供可能提供的最好的內(nèi)核。當你提交了一個補丁等待被收錄時，它會被且僅被該領域的技術權威所檢查。所以，你應該期待什么呢？
－ 批評
－ 評論
－ 被要求改動
－ 被要求解釋
－ 沉默

記住，這是讓你的補丁進入內(nèi)核的一部分。你必須能夠接受對你的補丁的批評和評論，在技術的層面上評估它，然后要么對你的補丁作出修改，要么提供清晰而言簡意賅的理由解釋為什么不應該做改動。如果沒有對你的補丁的回復，等幾天再試一次，有時候在流量很大的時候信件可能丟失，或被人忽略遺忘了。

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

在一個尋找可能存在的最好的技術解決方案的社區(qū)里，關于一個補丁怎樣的有用必定會存在不同的意見。你應該采取合作的態(tài)度，愿意改變你的意見以適應內(nèi)核的需要�；蛘咧辽僭敢庾C明的你的觀點有價值。記住，犯錯誤是可以接受的，只要你愿意朝著正確的解決方案努力。

如果對于你的第一個補丁的回應只是一些要求你改正的意見，這很正常。這并不意味著你的補丁將不會被接受，這些意見也不是針對你本人的。你要做的只是改正你的補丁然后重新發(fā)送。

內(nèi)核社區(qū)和企業(yè)架構的區(qū)別
-------------------

內(nèi)核社區(qū)和大多數(shù)傳統(tǒng)的企業(yè)開發(fā)環(huán)境工作形式不一樣。這里有一個列表你可以嘗試遵照執(zhí)行以避免出現(xiàn)問題：
關于你提交的補丁的好的說法：
－ “這個可以解決多個問題�！�
－ “這個刪除了2000行代碼�！�
－ “這個補丁解釋了我嘗試想描述的東西�！�
－ “我在5個不同的架構上測試了它……”
－ “這里是一系列的小補丁，它們可以……”
－ “這個在典型的機器上可以提高表現(xiàn)……”

你應該避免的壞的說法：
－ “我們在AIX/ptx/Solaris上都是這樣做的，所以它一定是好的……”
－ “我已經(jīng)這樣做20年了，所以……”
－ “我的公司需要這樣做來掙錢”
－ “這是我的一千頁的設計文檔，它解釋了我的想法”
－ “我已經(jīng)在它上面花了6個月的心血……”
－ “這里是一個5000行的補丁，它……”
－ “我重新寫了所有現(xiàn)有的垃圾，在這里……”
－ “我有完成期限，這個補丁必須現(xiàn)在被應用�！�

內(nèi)核社區(qū)和大多數(shù)傳統(tǒng)軟件工程工作環(huán)境的另一個不同是沒有面對面的交流。使用email和irc作為主要交流形式的好處之一是不會存在基于性別或者種族的歧視。Linux內(nèi)核工作環(huán)境接受女士和少數(shù)民族，因為你的存在只是一個email地址。國際化也幫助我們實現(xiàn)了平等的工作環(huán)境，因為你無法根據(jù)一個人的名字來判斷一個人的性別。一個男人可以叫Andrea，一個女人可以叫Pat。大多數(shù)為Linux內(nèi)核做過工作或者發(fā)表過觀點的女性對此都深有體會。

對于不習慣英語的人來說語言障礙可能會導致一些問題。對于語言的良好的掌握可以令思想在郵件列表上交流的更暢通，所以建議你在發(fā)送郵件之前檢查一下你的郵件內(nèi)容在英語里是否有意義。

打散你的補丁
---------

Linux內(nèi)核社區(qū)不樂意接受大段的代碼，一般會在收到時立刻丟棄。你的補丁需要適當?shù)谋唤榻B，討論，并打散為細小的，獨立的片段。這幾乎和公司里經(jīng)常做的完全背道而馳。你的提議必須在開發(fā)流程的早期提出，這樣你才可以收到足夠的關于你的工作的回饋。這也會令社區(qū)感覺到你是在和他們一起工作，而不是利用他們作為傾倒你的補丁的場所。但是，請不要一次向郵件列表發(fā)送超過50封email，你的一系列補丁的個數(shù)應該永遠小于這個數(shù)字。

把補丁打散的理由如下：

1) 小的補丁增加了你的補丁被應用的機會，因為它不需要花太多的時間和精力來檢查它的正確性。一個5行的補丁，一個維護者只要花一秒鐘瞟一眼然后就可以應用了。不過，一個500行的補丁需要一個小時來檢查是否有錯誤（所需的時間跟補丁的大小差不多成指數(shù)級別增長）。

小補丁也使得在出錯的時候很容易debug。如果出了問題，小補丁可以一個一個的取消，大補丁就比較麻煩了。
2) 除了要把補丁打散之外，在提交之前還要重寫和簡化（或者只是簡單的重排序）你的補丁。這一點也是很重要的。

這里有一個內(nèi)核開發(fā)者Al Viro所做的類比：
“想一下一個老師為一個數(shù)學系學生批改作業(yè)的情景。老師不希望看到學生在回答出正確答案之前的嘗試和失敗。他們想看到最清楚的，最優(yōu)美的答案。一個好學生了解這一點，并不會在得到最終答案之前把他們的中間結(jié)果提交上去。

對于內(nèi)核開發(fā)來說同樣是這樣。維護者和評論者不希望看到問題的解決方案背后的思考過程。他們想看到一個簡單和優(yōu)美的解決方案�！�

提供一個優(yōu)美的解決方案和同社區(qū)一起工作討論你未完成的作品，要維持此二者之間的平衡可能是一個很有挑戰(zhàn)性的事情。所以應及早的參與一個開發(fā)流程以獲得回饋來改進你的作品，但仍要保證你的補丁的小塊頭，這樣它們可能提早被接受，哪怕是在你的整個作品還為完成時。

也請注意，如果你的補丁尚未完成而且還需要修改，請不要提交。

證明你的改動
---------

除了打散你的補丁之外，讓Linux社區(qū)理解為什么他們要加入這項改動也是很重要的。新的功能必須要被證實它們需要而且有用。

為你的改動寫文檔
-------------

在你提交補丁時，要格外留心你在email里說的話。這些信息將會成為這個補丁的ChangeLog信息，將會被保留從而使每個人任何時候都可以看到。它必須完整的描述這個補丁，包括：
－ 為什么這個改動是需要的
－ 這個補丁的整體設計方案
－ 實現(xiàn)細節(jié)
－ 測試結(jié)果

欲知這個過程到底看起來是什么樣子的，請看這個文檔的ChangeLog部分：
“The Perfect Patch”
http://www.zip.com.au/~akpm/linux/patches/stuff/tpp.txt




所有這些事情有時候很難做到。要想完美做到這些要求可能需要幾年的時間。這是一個持續(xù)的發(fā)展過程，需要很多耐心和決心。但是不要放棄，這是可以實現(xiàn)的。很多人已經(jīng)做到了這一點，每個人都經(jīng)歷過你現(xiàn)在這個階段。



-------------
感謝Paolo Ciarrocchi允許我在他所寫的文章的基礎上寫成本文的“開發(fā)流程”部分，感謝Randy Dunlap和Gerrit Huizenga為了他們應該說的和不該說的一些事情。也感謝Pat Mochel, Hanna Linder, Randy Dunlap, Kay Sievers, Vojtech Pavlik, Jan Kara, Josh Boyer, Kees Cook, Andrew Morton, Andi Kleen, Vadim Lobanov, Jesper Juhl, Adrian Bunk, Keri Harris, Frans Pop,David A. Wheeler, Junio Hamano, Michael Kerrisk, 和 Alex Shepard為了他們對于本文初稿的評論和意見。



維護者： Greg Kroah-Hartman <greg@kroah.com>

[ 本帖最后由 leviathan.alan 于 2006-6-20 09:51 編輯 ]



歡迎光臨 Chinaunix (http://www.72891.cn/) Powered by Discuz! X3.2