免费视频淫片aa毛片_日韩高清在线亚洲专区vr_日韩大片免费观看视频播放_亚洲欧美国产精品完整版

打開APP
userphoto
未登錄

開通VIP,暢享免費(fèi)電子書等14項(xiàng)超值服

開通VIP
如何參與linux 內(nèi)核開發(fā)
如果想評(píng)論或更新本文的內(nèi)容,請(qǐng)直接聯(lián)系原文檔的維護(hù)者。如果你使用英文
交流有困難的話,也可以向中文版維護(hù)者求助。如果本翻譯更新不及時(shí)或者翻
譯存在問題,請(qǐng)聯(lián)系中文版維護(hù)者。
英文版維護(hù)者: Greg Kroah-Hartman <greg@kroah.com>
中文版維護(hù)者: 李陽(yáng) Li Yang <leoli@freescale.com>
中文版翻譯者: 李陽(yáng) Li Yang <leoli@freescale.com>
中文版校譯者: 鐘宇 TripleX Chung <xxx.phy@gmail.com>
               陳琦 Maggie Chen <chenqi@beyondsoft.com>
               王聰 Wang Cong <xiyou.wangcong@gmail.com>
以下為正文
---------------------------------------------------------------------
如何參與Linux內(nèi)核開發(fā)
---------------------
這是一篇將如何參與Linux內(nèi)核開發(fā)的相關(guān)問題一網(wǎng)打盡的終極秘笈。它將指導(dǎo)你
成為一名Linux內(nèi)核開發(fā)者,并且學(xué)會(huì)如何同Linux內(nèi)核開發(fā)社區(qū)合作。它盡可能不
包括任何關(guān)于內(nèi)核編程的技術(shù)細(xì)節(jié),但會(huì)給你指引一條獲得這些知識(shí)的正確途徑。
如果這篇文章中的任何內(nèi)容不再適用,請(qǐng)給文末列出的文件維護(hù)者發(fā)送補(bǔ)丁。
入門
----
你想了解如何成為一名Linux內(nèi)核開發(fā)者?或者老板吩咐你“給這個(gè)設(shè)備寫個(gè)Linux
驅(qū)動(dòng)程序”?這篇文章的目的就是教會(huì)你達(dá)成這些目標(biāo)的全部訣竅,它將描述你需
要經(jīng)過的流程以及給出如何同內(nèi)核社區(qū)合作的一些提示。它還將試圖解釋內(nèi)核社區(qū)
為何這樣運(yùn)作。
Linux內(nèi)核大部分是由C語(yǔ)言寫成的,一些體系結(jié)構(gòu)相關(guān)的代碼用到了匯編語(yǔ)言。要
參與內(nèi)核開發(fā),你必須精通C語(yǔ)言。除非你想為某個(gè)架構(gòu)開發(fā)底層代碼,否則你并
不需要了解(任何體系結(jié)構(gòu)的)匯編語(yǔ)言。下面列舉的書籍雖然不能替代扎實(shí)的C
語(yǔ)言教育和多年的開發(fā)經(jīng)驗(yàn),但如果需要的話,做為參考還是不錯(cuò)的:
 - "The C Programming Language" by Kernighan and Ritchie [Prentice Hall]
   《C程序設(shè)計(jì)語(yǔ)言(第2版·新版)》(徐寶文 李志 譯)[機(jī)械工業(yè)出版社]
 - "Practical C Programming" by Steve Oualline [O'Reilly]
   《實(shí)用C語(yǔ)言編程(第三版)》(郭大海 譯)[中國(guó)電力出版社]
 - "C: A Reference Manual" by Harbison and Steele [Prentice Hall]
   《C語(yǔ)言參考手冊(cè)(原書第5版)》(邱仲潘 等譯)[機(jī)械工業(yè)出版社]
Linux內(nèi)核使用GNU C和GNU工具鏈開發(fā)。雖然它遵循ISO C89標(biāo)準(zhǔn),但也用到了一些
標(biāo)準(zhǔn)中沒有定義的擴(kuò)展。內(nèi)核是自給自足的C環(huán)境,不依賴于標(biāo)準(zhǔn)C庫(kù)的支持,所以
并不支持C標(biāo)準(zhǔn)中的部分定義。比如long long類型的大數(shù)除法和浮點(diǎn)運(yùn)算就不允許
使用。有時(shí)候確實(shí)很難弄清楚內(nèi)核對(duì)工具鏈的要求和它所使用的擴(kuò)展,不幸的是目
前還沒有明確的參考資料可以解釋它們。請(qǐng)查閱gcc信息頁(yè)(使用“info gcc”命令
顯示)獲得一些這方面信息。
請(qǐng)記住你是在學(xué)習(xí)怎么和已經(jīng)存在的開發(fā)社區(qū)打交道。它由一群形形色色的人組成,
他們對(duì)代碼、風(fēng)格和過程有著很高的標(biāo)準(zhǔn)。這些標(biāo)準(zhǔn)是在長(zhǎng)期實(shí)踐中總結(jié)出來(lái)的,
適應(yīng)于地理上分散的大型開發(fā)團(tuán)隊(duì)。它們已經(jīng)被很好得整理成檔,建議你在開發(fā)
之前盡可能多的學(xué)習(xí)這些標(biāo)準(zhǔn),而不要期望別人來(lái)適應(yīng)你或者你公司的行為方式。
法律問題
--------
Linux內(nèi)核源代碼都是在GPL(通用公共許可證)的保護(hù)下發(fā)布的。要了解這種許可
的細(xì)節(jié)請(qǐng)查看源代碼主目錄下的COPYING文件。如果你對(duì)它還有更深入問題請(qǐng)聯(lián)系
律師,而不要在Linux內(nèi)核郵件組上提問。因?yàn)猷]件組里的人并不是律師,不要期
望他們的話有法律效力。
對(duì)于GPL的常見問題和解答,請(qǐng)?jiān)L問以下鏈接:
http://www.gnu.org/licenses/gpl-faq.html
文檔
----
Linux內(nèi)核代碼中包含有大量的文檔。這些文檔對(duì)于學(xué)習(xí)如何與內(nèi)核社區(qū)互動(dòng)有著
不可估量的價(jià)值。當(dāng)一個(gè)新的功能被加入內(nèi)核,最好把解釋如何使用這個(gè)功能的文
檔也放進(jìn)內(nèi)核。當(dāng)內(nèi)核的改動(dòng)導(dǎo)致面向用戶空間的接口發(fā)生變化時(shí),最好將相關(guān)信
息或手冊(cè)頁(yè)(manpages)的補(bǔ)丁發(fā)到mtk.manpages@gmail.com,以向手冊(cè)頁(yè)(manpages)
的維護(hù)者解釋這些變化。
以下是內(nèi)核代碼中需要閱讀的文檔:
  README
    文件簡(jiǎn)要介紹了Linux內(nèi)核的背景,并且描述了如何配置和編譯內(nèi)核。內(nèi)核的
    新用戶應(yīng)該從這里開始。
  Documentation/Changes
    文件給出了用來(lái)編譯和使用內(nèi)核所需要的最小軟件包列表。
  Documentation/CodingStyle
    描述Linux內(nèi)核的代碼風(fēng)格和理由。所有新代碼需要遵守這篇文檔中定義的規(guī)
    范。大多數(shù)維護(hù)者只會(huì)接收符合規(guī)定的補(bǔ)丁,很多人也只會(huì)幫忙檢查符合風(fēng)格
    的代碼。
  Documentation/SubmittingPatches
  Documentation/SubmittingDrivers
    這兩份文檔明確描述如何創(chuàng)建和發(fā)送補(bǔ)丁,其中包括(但不僅限于):
       - 郵件內(nèi)容
       - 郵件格式
       - 選擇收件人
    遵守這些規(guī)定并不能保證提交成功(因?yàn)樗醒a(bǔ)丁需要通過嚴(yán)格的內(nèi)容和風(fēng)格
    審查),但是忽視他們幾乎就意味著失敗。
    其他關(guān)于如何正確地生成補(bǔ)丁的優(yōu)秀文檔包括:
    "The Perfect Patch"
        http://userweb.kernel.org/~akpm/stuff/tpp.txt
    "Linux kernel patch submission format"
        http://linux.yyz.us/patch-format.html
  Documentation/stable_api_nonsense.txt
    論證內(nèi)核為什么特意不包括穩(wěn)定的內(nèi)核內(nèi)部API,也就是說(shuō)不包括像這樣的特
    性:
       - 子系統(tǒng)中間層(為了兼容性?)
       - 在不同操作系統(tǒng)間易于移植的驅(qū)動(dòng)程序
       - 減緩(甚至阻止)內(nèi)核代碼的快速變化
    這篇文檔對(duì)于理解Linux的開發(fā)哲學(xué)至關(guān)重要。對(duì)于將開發(fā)平臺(tái)從其他操作系
    統(tǒng)轉(zhuǎn)移到Linux的人來(lái)說(shuō)也很重要。
  Documentation/SecurityBugs
    如果你認(rèn)為自己發(fā)現(xiàn)了Linux內(nèi)核的安全性問題,請(qǐng)根據(jù)這篇文檔中的步驟來(lái)
    提醒其他內(nèi)核開發(fā)者并幫助解決這個(gè)問題。
  Documentation/ManagementStyle
    描述內(nèi)核維護(hù)者的工作方法及其共有特點(diǎn)。這對(duì)于剛剛接觸內(nèi)核開發(fā)(或者對(duì)
    它感到好奇)的人來(lái)說(shuō)很重要,因?yàn)樗忉屃撕芏鄬?duì)于內(nèi)核維護(hù)者獨(dú)特行為的
    普遍誤解與迷惑。
  Documentation/stable_kernel_rules.txt
    解釋了穩(wěn)定版內(nèi)核發(fā)布的規(guī)則,以及如何將改動(dòng)放入這些版本的步驟。
  Documentation/kernel-docs.txt
    有助于內(nèi)核開發(fā)的外部文檔列表。如果你在內(nèi)核自帶的文檔中沒有找到你想找
    的內(nèi)容,可以查看這些文檔。
  Documentation/applying-patches.txt
    關(guān)于補(bǔ)丁是什么以及如何將它打在不同內(nèi)核開發(fā)分支上的好介紹
內(nèi)核還擁有大量從代碼自動(dòng)生成的文檔。它包含內(nèi)核內(nèi)部API的全面介紹以及如何
妥善處理加鎖的規(guī)則。生成的文檔會(huì)放在 Documentation/DocBook/目錄下。在內(nèi)
核源碼的主目錄中使用以下不同命令將會(huì)分別生成PDF、Postscript、HTML和手冊(cè)
頁(yè)等不同格式的文檔:
    make pdfdocs
    make psdocs
    make htmldocs
    make mandocs
如何成為內(nèi)核開發(fā)者
------------------
如果你對(duì)Linux內(nèi)核開發(fā)一無(wú)所知,你應(yīng)該訪問“Linux內(nèi)核新手”計(jì)劃:
http://kernelnewbies.org
它擁有一個(gè)可以問各種最基本的內(nèi)核開發(fā)問題的郵件列表(在提問之前一定要記得
查找已往的郵件,確認(rèn)是否有人已經(jīng)回答過相同的問題)。它還擁有一個(gè)可以獲得
實(shí)時(shí)反饋的IRC聊天頻道,以及大量對(duì)于學(xué)習(xí)Linux內(nèi)核開發(fā)相當(dāng)有幫助的文檔。
網(wǎng)站簡(jiǎn)要介紹了源代碼組織結(jié)構(gòu)、子系統(tǒng)劃分以及目前正在進(jìn)行的項(xiàng)目(包括內(nèi)核
中的和單獨(dú)維護(hù)的)。它還提供了一些基本的幫助信息,比如如何編譯內(nèi)核和打補(bǔ)
丁。
如果你想加入內(nèi)核開發(fā)社區(qū)并協(xié)助完成一些任務(wù),卻找不到從哪里開始,可以訪問
“Linux內(nèi)核房管員”計(jì)劃:
http://kernelnewbies.org/KernelJanitors
這是極佳的起點(diǎn)。它提供一個(gè)相對(duì)簡(jiǎn)單的任務(wù)列表,列出內(nèi)核代碼中需要被重新
整理或者改正的地方。通過和負(fù)責(zé)這個(gè)計(jì)劃的開發(fā)者們一同工作,你會(huì)學(xué)到將補(bǔ)丁
集成進(jìn)內(nèi)核的基本原理。如果還沒有決定下一步要做什么的話,你還可能會(huì)得到方
向性的指點(diǎn)。
如果你已經(jīng)有一些現(xiàn)成的代碼想要放到內(nèi)核中,但是需要一些幫助來(lái)使它們擁有正
確的格式。請(qǐng)?jiān)L問“內(nèi)核導(dǎo)師”計(jì)劃。這個(gè)計(jì)劃就是用來(lái)幫助你完成這個(gè)目標(biāo)的。它
是一個(gè)郵件列表,地址如下:
http://selenic.com/mailman/listinfo/kernel-mentors
在真正動(dòng)手修改內(nèi)核代碼之前,理解要修改的代碼如何運(yùn)作是必需的。要達(dá)到這個(gè)
目的,沒什么辦法比直接讀代碼更有效了(大多數(shù)花招都會(huì)有相應(yīng)的注釋),而且
一些特制的工具還可以提供幫助。例如,“Linux代碼交叉引用”項(xiàng)目就是一個(gè)值得
特別推薦的幫助工具,它將源代碼顯示在有編目和索引的網(wǎng)頁(yè)上。其中一個(gè)更新及
時(shí)的內(nèi)核源碼庫(kù),可以通過以下地址訪問:
http://sosdg.org/~coywolf/lxr/
開發(fā)流程
--------
目前Linux內(nèi)核開發(fā)流程包括幾個(gè)“主內(nèi)核分支”和很多子系統(tǒng)相關(guān)的內(nèi)核分支。這
些分支包括:
  - 2.6.x主內(nèi)核源碼樹
  - 2.6.x.y -stable內(nèi)核源碼樹
  - 2.6.x -git內(nèi)核補(bǔ)丁集
  - 2.6.x -mm內(nèi)核補(bǔ)丁集
  - 子系統(tǒng)相關(guān)的內(nèi)核源碼樹和補(bǔ)丁集
2.6.x內(nèi)核主源碼樹
-----------------
2.6.x內(nèi)核是由Linus Torvalds(Linux的創(chuàng)造者)親自維護(hù)的。你可以在
kernel.org網(wǎng)站的pub/linux/kernel/v2.6/目錄下找到它。它的開發(fā)遵循以下步
驟:
  - 每當(dāng)一個(gè)新版本的內(nèi)核被發(fā)布,為期兩周的集成窗口將被打開。在這段時(shí)間里
    維護(hù)者可以向Linus提交大段的修改,通常這些修改已經(jīng)被放到-mm內(nèi)核中幾個(gè)
    星期了。提交大量修改的首選方式是使用git工具(內(nèi)核的代碼版本管理工具
    ,更多的信息可以在http://git.or.cz/獲?。?,不過使用普通補(bǔ)丁也是可以
    的。
  - 兩個(gè)星期以后-rc1版本內(nèi)核發(fā)布。之后只有不包含可能影響整個(gè)內(nèi)核穩(wěn)定性的
    新功能的補(bǔ)丁才可能被接受。請(qǐng)注意一個(gè)全新的驅(qū)動(dòng)程序(或者文件系統(tǒng))有
    可能在-rc1后被接受是因?yàn)檫@樣的修改完全獨(dú)立,不會(huì)影響其他的代碼,所以
    沒有造成內(nèi)核退步的風(fēng)險(xiǎn)。在-rc1以后也可以用git向Linus提交補(bǔ)丁,不過所
    有的補(bǔ)丁需要同時(shí)被發(fā)送到相應(yīng)的公眾郵件列表以征詢意見。
  - 當(dāng)Linus認(rèn)為當(dāng)前的git源碼樹已經(jīng)達(dá)到一個(gè)合理健全的狀態(tài)足以發(fā)布供人測(cè)試
    時(shí),一個(gè)新的-rc版本就會(huì)被發(fā)布。計(jì)劃是每周都發(fā)布新的-rc版本。
  - 這個(gè)過程一直持續(xù)下去直到內(nèi)核被認(rèn)為達(dá)到足夠穩(wěn)定的狀態(tài),持續(xù)時(shí)間大概是
    6個(gè)星期。
  - 以下地址跟蹤了在每個(gè)-rc發(fā)布中發(fā)現(xiàn)的退步列表:
    http://kernelnewbies.org/known_regressions
關(guān)于內(nèi)核發(fā)布,值得一提的是Andrew Morton在linux-kernel郵件列表中如是說(shuō):
“沒有人知道新內(nèi)核何時(shí)會(huì)被發(fā)布,因?yàn)榘l(fā)布是根據(jù)已知bug的情況來(lái)決定
的,而不是根據(jù)一個(gè)事先制定好的時(shí)間表?!?/div>
2.6.x.y -stable(穩(wěn)定版)內(nèi)核源碼樹
-----------------------------------
由4個(gè)數(shù)字組成的內(nèi)核版本號(hào)說(shuō)明此內(nèi)核是-stable版本。它們包含基于2.6.x版本
內(nèi)核的相對(duì)較小且至關(guān)重要的修補(bǔ),這些修補(bǔ)針對(duì)安全性問題或者嚴(yán)重的內(nèi)核退步。
這種版本的內(nèi)核適用于那些期望獲得最新的穩(wěn)定版內(nèi)核并且不想?yún)⑴c測(cè)試開發(fā)版或
者實(shí)驗(yàn)版的用戶。
如果沒有2.6.x.y版本內(nèi)核存在,那么最新的2.6.x版本內(nèi)核就相當(dāng)于是當(dāng)前的穩(wěn)定
版內(nèi)核。
2.6.x.y版本由“穩(wěn)定版”小組(郵件地址<stable@kernel.org>)維護(hù),一般隔周發(fā)
布新版本。
內(nèi)核源碼中的Documentation/stable_kernel_rules.txt文件具體描述了可被穩(wěn)定
版內(nèi)核接受的修改類型以及發(fā)布的流程。
2.6.x -git補(bǔ)丁集
----------------
Linus的內(nèi)核源碼樹的每日快照,這個(gè)源碼樹是由git工具管理的(由此得名)。這
些補(bǔ)丁通常每天更新以反映Linus的源碼樹的最新狀態(tài)。它們比-rc版本的內(nèi)核源碼
樹更具試驗(yàn)性質(zhì),因?yàn)檫@個(gè)補(bǔ)丁集是全自動(dòng)生成的,沒有任何人來(lái)確認(rèn)其是否真正
健全。
2.6.x -mm補(bǔ)丁集
---------------
這是由Andrew Morton維護(hù)的試驗(yàn)性內(nèi)核補(bǔ)丁集。Andrew將所有子系統(tǒng)的內(nèi)核源碼
和補(bǔ)丁拼湊到一起,并且加入了大量從linux-kernel郵件列表中采集的補(bǔ)丁。這個(gè)
源碼樹是新功能和補(bǔ)丁的試煉場(chǎng)。當(dāng)補(bǔ)丁在-mm補(bǔ)丁集里證明了其價(jià)值以后Andrew
或者相應(yīng)子系統(tǒng)的維護(hù)者會(huì)將補(bǔ)丁發(fā)給Linus以便集成進(jìn)主內(nèi)核源碼樹。
在將所有新補(bǔ)丁發(fā)給Linus以集成到主內(nèi)核源碼樹之前,我們非常鼓勵(lì)先把這些補(bǔ)
丁放在-mm版內(nèi)核源碼樹中進(jìn)行測(cè)試。
這些內(nèi)核版本不適合在需要穩(wěn)定運(yùn)行的系統(tǒng)上運(yùn)行,因?yàn)檫\(yùn)行它們比運(yùn)行任何其他
內(nèi)核分支都更具有風(fēng)險(xiǎn)。
如果你想為內(nèi)核開發(fā)進(jìn)程提供幫助,請(qǐng)嘗試并使用這些內(nèi)核版本,并在
linux-kernel郵件列表中提供反饋,告訴大家你遇到了問題還是一切正常。
通常-mm版補(bǔ)丁集不光包括這些額外的試驗(yàn)性補(bǔ)丁,還包括發(fā)布時(shí)-git版主源碼樹
中的改動(dòng)。
-mm版內(nèi)核沒有固定的發(fā)布周期,但是通常在每?jī)蓚€(gè)-rc版內(nèi)核發(fā)布之間都會(huì)有若干
個(gè)-mm版內(nèi)核發(fā)布(一般是1至3個(gè))。
子系統(tǒng)相關(guān)內(nèi)核源碼樹和補(bǔ)丁集
----------------------------
相當(dāng)一部分內(nèi)核子系統(tǒng)開發(fā)者會(huì)公開他們自己的開發(fā)源碼樹,以便其他人能了解內(nèi)
核的不同領(lǐng)域正在發(fā)生的事情。如上所述,這些源碼樹會(huì)被集成到-mm版本內(nèi)核中。
下面是目前可用的一些內(nèi)核源碼樹的列表:
  通過git管理的源碼樹:
    - Kbuild開發(fā)源碼樹, Sam Ravnborg <sam@ravnborg.org>
git.kernel.org:/pub/scm/linux/kernel/git/sam/kbuild.git
    - ACPI開發(fā)源碼樹, Len Brown <len.brown@intel.com>
git.kernel.org:/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6.git
    - 塊設(shè)備開發(fā)源碼樹, Jens Axboe <axboe@suse.de>
git.kernel.org:/pub/scm/linux/kernel/git/axboe/linux-2.6-block.git
    - DRM開發(fā)源碼樹, Dave Airlie <airlied@linux.ie>
git.kernel.org:/pub/scm/linux/kernel/git/airlied/drm-2.6.git
    - ia64開發(fā)源碼樹, Tony Luck <tony.luck@intel.com>
git.kernel.org:/pub/scm/linux/kernel/git/aegl/linux-2.6.git
    - ieee1394開發(fā)源碼樹, Jody McIntyre <scjody@modernduck.com>
git.kernel.org:/pub/scm/linux/kernel/git/scjody/ieee1394.git
    - infiniband開發(fā)源碼樹, Roland Dreier <rolandd@cisco.com>
git.kernel.org:/pub/scm/linux/kernel/git/roland/infiniband.git
    - libata開發(fā)源碼樹, Jeff Garzik <jgarzik@pobox.com>
git.kernel.org:/pub/scm/linux/kernel/git/jgarzik/libata-dev.git
    - 網(wǎng)絡(luò)驅(qū)動(dòng)程序開發(fā)源碼樹, Jeff Garzik <jgarzik@pobox.com>
git.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git
    - pcmcia開發(fā)源碼樹, Dominik Brodowski <linux@dominikbrodowski.net>
git.kernel.org:/pub/scm/linux/kernel/git/brodo/pcmcia-2.6.git
    - SCSI開發(fā)源碼樹, James Bottomley <James.Bottomley@SteelEye.com>
git.kernel.org:/pub/scm/linux/kernel/git/jejb/scsi-misc-2.6.git
  使用quilt管理的補(bǔ)丁集:
    - USB, PCI, 驅(qū)動(dòng)程序核心和I2C, Greg Kroah-Hartman <gregkh@linuxfoundation.org>
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/
  其他內(nèi)核源碼樹可以在http://git.kernel.org的列表中和MAINTAINERS文件里
  找到。
報(bào)告bug
-------
bugzilla.kernel.org是Linux內(nèi)核開發(fā)者們用來(lái)跟蹤內(nèi)核Bug的網(wǎng)站。我們鼓勵(lì)用
戶在這個(gè)工具中報(bào)告找到的所有bug。如何使用內(nèi)核bugzilla的細(xì)節(jié)請(qǐng)?jiān)L問:
http://test.kernel.org/bugzilla/faq.html
內(nèi)核源碼主目錄中的REPORTING-BUGS文件里有一個(gè)很好的模板。它指導(dǎo)用戶如何報(bào)
告可能的內(nèi)核bug以及需要提供哪些信息來(lái)幫助內(nèi)核開發(fā)者們找到問題的根源。
利用bug報(bào)告
-----------
練習(xí)內(nèi)核開發(fā)技能的最好辦法就是修改其他人報(bào)告的bug。你不光可以幫助內(nèi)核變
得更加穩(wěn)定,還可以學(xué)會(huì)如何解決實(shí)際問題從而提高自己的技能,并且讓其他開發(fā)
者感受到你的存在。修改bug是贏得其他開發(fā)者贊譽(yù)的最好辦法,因?yàn)椴⒉皇呛芏?/div>
人都喜歡浪費(fèi)時(shí)間去修改別人報(bào)告的bug。
要嘗試修改已知的bug,請(qǐng)?jiān)L問http://bugzilla.kernel.org網(wǎng)址。如果你想獲得
最新bug的通知,可以訂閱bugme-new郵件列表(只有新的bug報(bào)告會(huì)被寄到這里)
或者訂閱bugme-janitor郵件列表(所有bugzilla的變動(dòng)都會(huì)被寄到這里)。
https://lists.linux-foundation.org/mailman/listinfo/bugme-new
https://lists.linux-foundation.org/mailman/listinfo/bugme-janitors
郵件列表
--------
正如上面的文檔所描述,大多數(shù)的骨干內(nèi)核開發(fā)者都加入了Linux Kernel郵件列
表。如何訂閱和退訂列表的細(xì)節(jié)可以在這里找到:
http://vger.kernel.org/vger-lists.html#linux-kernel
網(wǎng)上很多地方都有這個(gè)郵件列表的存檔(archive)。可以使用搜索引擎來(lái)找到這些
存檔。比如:
http://dir.gmane.org/gmane.linux.kernel
在發(fā)信之前,我們強(qiáng)烈建議你先在存檔中搜索你想要討論的問題。很多已經(jīng)被詳細(xì)
討論過的問題只在郵件列表的存檔中可以找到。
大多數(shù)內(nèi)核子系統(tǒng)也有自己獨(dú)立的郵件列表來(lái)協(xié)調(diào)各自的開發(fā)工作。從
MAINTAINERS文件中可以找到不同話題對(duì)應(yīng)的郵件列表。
很多郵件列表架設(shè)在kernel.org服務(wù)器上。這些列表的信息可以在這里找到:
http://vger.kernel.org/vger-lists.html
在使用這些郵件列表時(shí),請(qǐng)記住保持良好的行為習(xí)慣。下面的鏈接提供了與這些列
表(或任何其它郵件列表)交流的一些簡(jiǎn)單規(guī)則,雖然內(nèi)容有點(diǎn)濫竽充數(shù)。
http://www.albion.com/netiquette/
當(dāng)有很多人回復(fù)你的郵件時(shí),郵件的抄送列表會(huì)變得很長(zhǎng)。請(qǐng)不要將任何人從抄送
列表中刪除,除非你有足夠的理由這么做。也不要只回復(fù)到郵件列表。請(qǐng)習(xí)慣于同
一封郵件接收兩次(一封來(lái)自發(fā)送者一封來(lái)自郵件列表),而不要試圖通過添加一
些奇特的郵件頭來(lái)解決這個(gè)問題,人們不會(huì)喜歡的。
記住保留你所回復(fù)內(nèi)容的上下文和源頭。在你回復(fù)郵件的頂部保留“某某某說(shuō)到……”
這幾行。將你的評(píng)論加在被引用的段落之間而不要放在郵件的頂部。
如果你在郵件中附帶補(bǔ)丁,請(qǐng)確認(rèn)它們是可以直接閱讀的純文本(如
Documentation/SubmittingPatches文檔中所述)。內(nèi)核開發(fā)者們不希望遇到附件
或者被壓縮了的補(bǔ)丁。只有這樣才能保證他們可以直接評(píng)論你的每行代碼。請(qǐng)確保
你使用的郵件發(fā)送程序不會(huì)修改空格和制表符。一個(gè)防范性的測(cè)試方法是先將郵件
發(fā)送給自己,然后自己嘗試是否可以順利地打上收到的補(bǔ)丁。如果測(cè)試不成功,請(qǐng)
調(diào)整或者更換你的郵件發(fā)送程序直到它正確工作為止。
總而言之,請(qǐng)尊重其他的郵件列表訂閱者。
同內(nèi)核社區(qū)合作
----------------
內(nèi)核社區(qū)的目標(biāo)就是提供盡善盡美的內(nèi)核。所以當(dāng)你提交補(bǔ)丁期望被接受進(jìn)內(nèi)核的
時(shí)候,它的技術(shù)價(jià)值以及其他方面都將被評(píng)審。那么你可能會(huì)得到什么呢?
  - 批評(píng)
  - 評(píng)論
  - 要求修改
  - 要求證明修改的必要性
  - 沉默
要記住,這些是把補(bǔ)丁放進(jìn)內(nèi)核的正常情況。你必須學(xué)會(huì)聽取對(duì)補(bǔ)丁的批評(píng)和評(píng)論,
從技術(shù)層面評(píng)估它們,然后要么重寫你的補(bǔ)丁要么簡(jiǎn)明扼要地論證修改是不必要
的。如果你發(fā)的郵件沒有得到任何回應(yīng),請(qǐng)過幾天后再試一次,因?yàn)橛袝r(shí)信件會(huì)湮
沒在茫茫信海中。
你不應(yīng)該做的事情:
  - 期望自己的補(bǔ)丁不受任何質(zhì)疑就直接被接受
  - 翻臉
  - 忽略別人的評(píng)論
  - 沒有按照別人的要求做任何修改就重新提交
在一個(gè)努力追尋最好技術(shù)方案的社區(qū)里,對(duì)于一個(gè)補(bǔ)丁有多少好處總會(huì)有不同的見
解。你必須要抱著合作的態(tài)度,愿意改變自己的觀點(diǎn)來(lái)適應(yīng)內(nèi)核的風(fēng)格?;蛘咧辽?/div>
愿意去證明你的想法是有價(jià)值的。記住,犯錯(cuò)誤是允許的,只要你愿意朝著正確的
方案去努力。
如果你的第一個(gè)補(bǔ)丁換來(lái)的是一堆修改建議,這是很正常的。這并不代表你的補(bǔ)丁
不會(huì)被接受,也不意味著有人和你作對(duì)。你只需要改正所有提出的問題然后重新發(fā)
送你的補(bǔ)丁。
內(nèi)核社區(qū)和公司文化的差異
------------------------
內(nèi)核社區(qū)的工作模式同大多數(shù)傳統(tǒng)公司開發(fā)隊(duì)伍的工作模式并不相同。下面這些例
子,可以幫助你避免某些可能發(fā)生問題:
  用這些話介紹你的修改提案會(huì)有好處:
    - 它同時(shí)解決了多個(gè)問題
    - 它刪除了2000行代碼
    - 這是補(bǔ)丁,它已經(jīng)解釋了我想要說(shuō)明的
    - 我在5種不同的體系結(jié)構(gòu)上測(cè)試過它……
    - 這是一系列小補(bǔ)丁用來(lái)……
    - 這個(gè)修改提高了普通機(jī)器的性能……
  應(yīng)該避免如下的說(shuō)法:
    - 我們?cè)贏IX/ptx/Solaris就是這么做的,所以這么做肯定是好的……
    - 我做這行已經(jīng)20年了,所以……
    - 為了我們公司賺錢考慮必須這么做
    - 這是我們的企業(yè)產(chǎn)品線所需要的
    - 這里是描述我觀點(diǎn)的1000頁(yè)設(shè)計(jì)文檔
    - 這是一個(gè)5000行的補(bǔ)丁用來(lái)……
    - 我重寫了現(xiàn)在亂七八糟的代碼,這就是……
    - 我被規(guī)定了最后期限,所以這個(gè)補(bǔ)丁需要立刻被接受
另外一個(gè)內(nèi)核社區(qū)與大部分傳統(tǒng)公司的軟件開發(fā)隊(duì)伍不同的地方是無(wú)法面對(duì)面地交
流。使用電子郵件和IRC聊天工具做為主要溝通工具的一個(gè)好處是性別和種族歧視
將會(huì)更少。Linux內(nèi)核的工作環(huán)境更能接受婦女和少數(shù)族群,因?yàn)槊總€(gè)人在別人眼
里只是一個(gè)郵件地址。國(guó)際化也幫助了公平的實(shí)現(xiàn),因?yàn)槟銦o(wú)法通過姓名來(lái)判斷人
的性別。男人有可能叫李麗,女人也有可能叫王剛。大多數(shù)在Linux內(nèi)核上工作過
并表達(dá)過看法的女性對(duì)在linux上工作的經(jīng)歷都給出了正面的評(píng)價(jià)。
對(duì)于一些不習(xí)慣使用英語(yǔ)的人來(lái)說(shuō),語(yǔ)言可能是一個(gè)引起問題的障礙。在郵件列表
中要正確地表達(dá)想法必需良好地掌握語(yǔ)言,所以建議你在發(fā)送郵件之前最好檢查一
下英文寫得是否正確。
拆分修改
--------
Linux內(nèi)核社區(qū)并不喜歡一下接收大段的代碼。修改需要被恰當(dāng)?shù)亟榻B、討論并且
拆分成獨(dú)立的小段。這幾乎完全和公司中的習(xí)慣背道而馳。你的想法應(yīng)該在開發(fā)最
開始的階段就讓大家知道,這樣你就可以及時(shí)獲得對(duì)你正在進(jìn)行的開發(fā)的反饋。這
樣也會(huì)讓社區(qū)覺得你是在和他們協(xié)作,而不是僅僅把他們當(dāng)作傾銷新功能的對(duì)象。
無(wú)論如何,你不要一次性地向郵件列表發(fā)送50封信,你的補(bǔ)丁序列應(yīng)該永遠(yuǎn)用不到
這么多。
將補(bǔ)丁拆開的原因如下:
1) 小的補(bǔ)丁更有可能被接受,因?yàn)樗鼈儾恍枰嗟臅r(shí)間和精力去驗(yàn)證其正確性。
   一個(gè)5行的補(bǔ)丁,可能在維護(hù)者看了一眼以后就會(huì)被接受。而500行的補(bǔ)丁則
   需要數(shù)個(gè)小時(shí)來(lái)審查其正確性(所需時(shí)間隨補(bǔ)丁大小增加大約呈指數(shù)級(jí)增長(zhǎng))。
   當(dāng)出了問題的時(shí)候,小的補(bǔ)丁也會(huì)讓調(diào)試變得非常容易。一個(gè)一個(gè)補(bǔ)丁地回溯
   將會(huì)比仔細(xì)剖析一個(gè)被打上的大補(bǔ)?。ㄟ@個(gè)補(bǔ)丁破壞了其他東西)容易得多。
2)不光發(fā)送小的補(bǔ)丁很重要,在提交之前重新編排、化簡(jiǎn)(或者僅僅重新排列)
   補(bǔ)丁也是很重要的。
這里有內(nèi)核開發(fā)者Al Viro打的一個(gè)比方:
“想象一個(gè)老師正在給學(xué)生批改數(shù)學(xué)作業(yè)。老師并不希望看到學(xué)生為了得
到正確解法所進(jìn)行的嘗試和產(chǎn)生的錯(cuò)誤。他希望看到的是最干凈最優(yōu)雅的
解答。好學(xué)生了解這點(diǎn),絕不會(huì)把最終解決之前的中間方案提交上去?!?/div>
內(nèi)核開發(fā)也是這樣。維護(hù)者和評(píng)審者不希望看到一個(gè)人在解決問題時(shí)的思
考過程。他們只希望看到簡(jiǎn)單和優(yōu)雅的解決方案。
直接給出一流的解決方案,和社區(qū)一起協(xié)作討論尚未完成的工作,這兩者之間似乎
很難找到一個(gè)平衡點(diǎn)。所以最好盡早開始收集有利于你進(jìn)行改進(jìn)的反饋;同時(shí)也要
保證修改分成很多小塊,這樣在整個(gè)項(xiàng)目都準(zhǔn)備好被包含進(jìn)內(nèi)核之前,其中的一部
分可能會(huì)先被接收。
必須了解這樣做是不可接受的:試圖將未完成的工作提交進(jìn)內(nèi)核,然后再找時(shí)間修
復(fù)。
證明修改的必要性
----------------
除了將補(bǔ)丁拆成小塊,很重要的一點(diǎn)是讓Linux社區(qū)了解他們?yōu)槭裁葱枰@樣修改。
你必須證明新功能是有人需要的并且是有用的。
記錄修改
--------
當(dāng)你發(fā)送補(bǔ)丁的時(shí)候,需要特別留意郵件正文的內(nèi)容。因?yàn)檫@里的信息將會(huì)做為補(bǔ)
丁的修改記錄(ChangeLog),會(huì)被一直保留以備大家查閱。它需要完全地描述補(bǔ)丁,
包括:
  - 為什么需要這個(gè)修改
  - 補(bǔ)丁的總體設(shè)計(jì)
  - 實(shí)現(xiàn)細(xì)節(jié)
  - 測(cè)試結(jié)果
想了解它具體應(yīng)該看起來(lái)像什么,請(qǐng)查閱以下文檔中的“ChangeLog”章節(jié):
  “The Perfect Patch”
   http://userweb.kernel.org/~akpm/stuff/tpp.txt
這些事情有時(shí)候做起來(lái)很難。要在任何方面都做到完美可能需要好幾年時(shí)間。這是
一個(gè)持續(xù)提高的過程,它需要大量的耐心和決心。只要不放棄,你一定可以做到。
很多人已經(jīng)做到了,而他們都曾經(jīng)和現(xiàn)在的你站在同樣的起點(diǎn)上。
---------------
感謝Paolo Ciarrocchi允許“開發(fā)流程”部分基于他所寫的文章
(http://www.kerneltravel.net/newbie/2.6-development_process),感謝Randy
Dunlap和Gerrit Huizenga完善了應(yīng)該說(shuō)和不該說(shuō)的列表。感謝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的評(píng)審、建議和貢獻(xiàn)。沒有他們的幫助,這篇文檔是不可
能完成的。
英文版維護(hù)者: Greg Kroah-Hartman <greg@kroah.com>
本站僅提供存儲(chǔ)服務(wù),所有內(nèi)容均由用戶發(fā)布,如發(fā)現(xiàn)有害或侵權(quán)內(nèi)容,請(qǐng)點(diǎn)擊舉報(bào)。
打開APP,閱讀全文并永久保存 查看更多類似文章
猜你喜歡
類似文章
生活服務(wù)
分享 收藏 導(dǎo)長(zhǎng)圖 關(guān)注 下載文章
綁定賬號(hào)成功
后續(xù)可登錄賬號(hào)暢享VIP特權(quán)!
如果VIP功能使用有故障,
可點(diǎn)擊這里聯(lián)系客服!

聯(lián)系客服