Documentation / zh_CN / HOWTO

Custom Search

Based on kernel version 2.6.33. Page generated on 2010-02-24 15:37 EST.

	Chinese translated version of Documentation/HOWTO
	
	If you have any comment or update to the content, please contact the
	original document maintainer directly.  However, if you have a problem
	communicating in English you can also ask the Chinese maintainer for
	help.  Contact the Chinese maintainer if this translation is outdated
	or if there is a problem with the translation.
	
	Maintainer: Greg Kroah-Hartman <greg[AT]kroah[DOT]com>
	Chinese maintainer: Li Yang <leoli[AT]freescale[DOT]com>
	---------------------------------------------------------------------
	Documentation/HOWTO 的中文翻译
	
	如果想评论或更新本文的内容，请直接�系原文档的维护者。如果你使用英文
	交�有困难的�，也�以�中文版维护者求助。如果本翻译更新��时或者翻
	译存在问题，请�系中文版维护者。
	
	英文版维护者： Greg Kroah-Hartman <greg[AT]kroah[DOT]com>
	中文版维护者： �阳  Li Yang <leoli[AT]freescale[DOT]com>
	中文版翻译者： �阳  Li Yang <leoli[AT]freescale[DOT]com>
	中文版校译者： 钟宇  TripleX Chung <xxx.phy[AT]gmail[DOT]com>
	               陈�  Maggie Chen <chenqi[AT]beyondsoft[DOT]com>
	               王�  Wang Cong <xiyou.wangcong[AT]gmail[DOT]com>
	
	以下为正文
	---------------------------------------------------------------------
	
	如何�与Linux内核开�
	---------------------
	
	这是一篇将如何�与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的常�问题和解答，请访问以下链接：
		http://www.gnu.org/licenses/gpl-faq.html
	
	
	文档
	----
	
	Linux内核代�中包�有大�的文档。这些文档对于学习如何与内核社区互动有�
	��估�的价值。当一个新的功能被加入内核，最好把解释如何使用这个功能的文
	档也放进内核。当内核的改动导致��用户空间的接��生�化时，最好将相关信
	�或手册页(manpages)的补��到mtk.manpages[AT]gmail[DOT]com，以�手册页(manpages)
	的维护者解释这些�化。
	
	以下是内核代�中需�阅读的文档：
	  README
	    文件简�介�了Linux内核的背景，并且�述了如何�置和编译内核。内核的
	    新用户应该从这里开始。
	
	  Documentation/Changes
	    文件给出了用�编译和使用内核所需�的最�软件包列表。
	
	  Documentation/CodingStyle
	    �述Linux内核的代�风格和�由。所有新代�需��守这篇文档中定义的规
	    范。大多数维护者�会接收符�规定的补�，很多人也�会帮忙检查符�风格
	    的代�。
	
	  Documentation/SubmittingPatches
	  Documentation/SubmittingDrivers
	    这两份文档明确�述如何创建和��补�，其中包括（但�仅�于)：
	       - 邮件内容
	       - 邮件格�
	       - 选择收件人
	    �守这些规定并�能���交�功（因为所有补�需�通过严格的内容和风格
	    审查），但是忽视他们几乎就�味�失败。
	
	    其他关于如何正确地生�补�的优秀文档包括：
	    "The Perfect Patch"
	        http://www.zip.com.au/~akpm/linux/patches/stuff/tpp.txt
	    "Linux kernel patch submission format"
	        http://linux.yyz.us/patch-format.html
	
	  Documentation/stable_api_nonsense.txt
	    论�内核为什么特��包括稳定的内核内部API，也就是说�包括�这样的特
	    性：
	       - �系统中间层（为了兼容性？）
	       - 在���作系统间易于移�的驱动程�
	       - �缓（甚至阻止）内核代�的快速�化
	    这篇文档对于�解Linux的开�哲学至关��。对于将开�平�从其他�作系
	    统转移到Linux的人�说也很��。
	
	  Documentation/SecurityBugs
	    如果你认为自己�现了Linux内核的安全性问题，请根�这篇文档中的步骤�
	    �醒其他内核开�者并帮助解决这个问题。
	
	  Documentation/ManagementStyle
	    �述内核维护者的工作方法�其共有特点。这对于刚刚接触内核开�（或者对
	    它感到好奇）的人�说很��，因为它解释了很多对于内核维护者独特行为的
	    普�误解与迷惑。
	
	  Documentation/stable_kernel_rules.txt
	    解释了稳定版内核�布的规则，以�如何将改动放入这些版本的步骤。
	
	  Documentation/kernel-docs.txt
	    有助于内核开�的外部文档列表。如果你在内核自带的文档中没有找到你想找
	    的内容，�以查看这些文档。
	
	  Documentation/applying-patches.txt
	    关于补�是什么以�如何将它打在��内核开�分支上的好介�
	
	内核还拥有大�从代�自动生�的文档。它包�内核内部API的全�介�以�如何
	妥善处�加�的规则。生�的文档会放在 Documentation/DocBook/目录下。在内
	核��的主目录中使用以下��命令将会分别生�PDF�Postscript�HTML和手册
	页等��格�的文档：
	    make pdfdocs
	    make psdocs
	    make htmldocs
	    make mandocs
	
	
	如何�为内核开�者
	------------------
	如果你对Linux内核开�一无所知，你应该访问“Linux内核新手�计划：
		http://kernelnewbies.org
	它拥有一个�以问��最基本的内核开�问题的邮件列表（在�问之�一定�记得
	查找已往的邮件，确认是�有人已�回答过相�的问题）。它还拥有一个�以获得
	实时�馈的IRC�天频�，以�大�对于学习Linux内核开�相当有帮助的文档。
	
	网站简�介�了�代�组织结构��系统划分以�目�正在进行的项目（包括内核
	中的和�独维护的）。它还�供了一些基本的帮助信�，比如如何编译内核和打补
	�。
	
	如果你想加入内核开�社区并�助完�一些任务，�找�到从哪里开始，�以访问
	“Linux内核房管员�计划：
		http://janitor.kernelnewbies.org/
	这是�佳的起点。它�供一个相对简�的任务列表，列出内核代�中需�被�新
	整�或者改正的地方。通过和负责这个计划的开�者们一�工作，你会学到将补�
	集�进内核的基本原�。如果还没有决定下一步��什么的�，你还�能会得到方
	�性的指点。
	
	如果你已�有一些现�的代�想�放到内核中，但是需�一些帮助�使它们拥有正
	确的格�。请访问“内核导师�计划。这个计划就是用�帮助你完�这个目标的。它
	是一个邮件列表，地�如下：
		http://selenic.com/mailman/listinfo/kernel-mentors
	
	在真正动手修改内核代�之�，�解�修改的代�如何�作是必需的。�达到这个
	目的，没什么办法比直接读代�更有效了（大多数花招都会有相应的注释），而且
	一些特制的工具还�以�供帮助。例如，“Linux代�交�引用�项目就是一个值得
	特别推�的帮助工具，它将�代�显示在有编目和索引的网页上。其中一个更新�
	时的内核��库，�以通过以下地�访问：
		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（Linux的创造者）亲自维护的。你�以在
	kernel.org网站的pub/linux/kernel/v2.6/目录下找到它。它的开��循以下步
	骤：
	  - �当一个新版本的内核被�布，为期两周的集�窗�将被打开。在这段时间里
	    维护者�以�Linus�交大段的修改，通常这些修改已�被放到-mm内核中几个
	    星期了。�交大�修改的首选方�是使用git工具（内核的代�版本管�工具
	    ，更多的信��以在http://git.or.cz/获�），�过使用普通补�也是�以
	    的。
	  - 两个星期以�-rc1版本内核�布。之��有�包��能影�整个内核稳定性的
	    新功能的补���能被接�。请注�一个全新的驱动程�（或者文件系统）有
	    �能在-rc1�被接�是因为这样的修改完全独立，�会影�其他的代�，所以
	    没有造�内核退步的风险。在-rc1以�也�以用git�Linus�交补�，�过所
	    有的补�需��时被��到相应的公众邮件列表以�询��。
	  - 当Linus认为当�的git��树已�达到一个���全的状�足以�布供人测试
	    时，一个新的-rc版本就会被�布。计划是�周都�布新的-rc版本。
	  - 这个过程一直�续下去直到内核被认为达到足够稳定的状�，�续时间大概是
	    6个星期。
	  - 以下地�跟踪了在�个-rc�布中�现的退步列表：
	    http://kernelnewbies.org/known_regressions
	
	关于内核�布，值得一�的是Andrew Morton在linux-kernel邮件列表中如是说：
		“没有人知�新内核何时会被�布，因为�布是根�已知bug的情况�决定
		的，而�是根�一个事先制定好的时间表。�
	
	
	2.6.x.y -stable（稳定版）内核��树
	-----------------------------------
	由4个数字组�的内核版本�说明此内核是-stable版本。它们包�基于2.6.x版本
	内核的相对较�且至关��的修补，这些修补针对安全性问题或者严�的内核退步。
	
	这�版本的内核适用于那些期望获得最新的稳定版内核并且�想�与测试开�版或
	者实验版的用户。
	
	如果没有2.6.x.y版本内核存在，那么最新的2.6.x版本内核就相当于是当�的稳定
	版内核。
	
	2.6.x.y版本由“稳定版��组（邮件地�<stable[AT]kernel[DOT]org>）维护，一般隔周�
	布新版本。
	
	内核��中的Documentation/stable_kernel_rules.txt文件具体�述了�被稳定
	版内核接�的修改类型以��布的�程。
	
	
	2.6.x -git补�集
	----------------
	Linus的内核��树的�日快照，这个��树是由git工具管�的（由此得�）。这
	些补�通常�天更新以�映Linus的��树的最新状�。它们比-rc版本的内核��
	树更具试验性质，因为这个补�集是全自动生�的，没有任何人�确认其是�真正
	�全。
	
	
	2.6.x -mm补�集
	---------------
	这是由Andrew Morton维护的试验性内核补�集。Andrew将所有�系统的内核��
	和补�拼凑到一起，并且加入了大�从linux-kernel邮件列表中采集的补�。这个
	��树是新功能和补�的试炼场。当补�在-mm补�集里�明了其价值以�Andrew
	或者相应�系统的维护者会将补��给Linus以便集�进主内核��树。
	
	在将所有新补��给Linus以集�到主内核��树之�，我们�常鼓励先把这些补
	�放在-mm版内核��树中进行测试。
	
	这些内核版本�适�在需�稳定�行的系统上�行，因为�行它们比�行任何其他
	内核分支都更具有风险。
	
	如果你想为内核开�进程�供帮助，请�试并使用这些内核版本，并在
	linux-kernel邮件列表中�供�馈，告诉大家你�到了问题还是一切正常。
	
	通常-mm版补�集�光包括这些�外的试验性补�，还包括�布时-git版主��树
	中的改动。
	
	-mm版内核没有固定的�布周期，但是通常在�两个-rc版内核�布之间都会有若干
	个-mm版内核�布（一般是1至3个）。
	
	
	�系统相关内核��树和补�集
	----------------------------
	相当一部分内核�系统开�者会公开他们自己的开���树，以便其他人能了解内
	核的��领域正在�生的事情。如上所述，这些��树会被集�到-mm版本内核中。
	
	下�是目��用的一些内核��树的列表：
	  通过git管�的��树：
	    - Kbuild开���树， Sam Ravnborg <sam[AT]ravnborg[DOT]org>
		git.kernel.org:/pub/scm/linux/kernel/git/sam/kbuild.git
	
	    - ACPI开���树, Len Brown <len.brown[AT]intel[DOT]com>
		git.kernel.org:/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6.git
	
	    - �设备开���树, Jens Axboe <axboe[AT]suse[DOT]de>
		git.kernel.org:/pub/scm/linux/kernel/git/axboe/linux-2.6-block.git
	
	    - DRM开���树, Dave Airlie <airlied[AT]linux[DOT]ie>
		git.kernel.org:/pub/scm/linux/kernel/git/airlied/drm-2.6.git
	
	    - ia64开���树, Tony Luck <tony.luck[AT]intel[DOT]com>
		git.kernel.org:/pub/scm/linux/kernel/git/aegl/linux-2.6.git
	
	    - ieee1394开���树, Jody McIntyre <scjody[AT]modernduck[DOT]com>
		git.kernel.org:/pub/scm/linux/kernel/git/scjody/ieee1394.git
	
	    - infiniband开���树, Roland Dreier <rolandd[AT]cisco[DOT]com>
		git.kernel.org:/pub/scm/linux/kernel/git/roland/infiniband.git
	
	    - libata开���树, Jeff Garzik <jgarzik[AT]pobox[DOT]com>
		git.kernel.org:/pub/scm/linux/kernel/git/jgarzik/libata-dev.git
	
	    - 网络驱动程�开���树, Jeff Garzik <jgarzik[AT]pobox[DOT]com>
		git.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git
	
	    - pcmcia开���树, Dominik Brodowski <linux[AT]dominikbrodowski[DOT]net>
		git.kernel.org:/pub/scm/linux/kernel/git/brodo/pcmcia-2.6.git
	
	    - SCSI开���树, James Bottomley <James.Bottomley[AT]SteelEye[DOT]com>
		git.kernel.org:/pub/scm/linux/kernel/git/jejb/scsi-misc-2.6.git
	
	  使用quilt管�的补�集：
	    - USB, PCI, 驱动程�核心和I2C, Greg Kroah-Hartman <gregkh[AT]suse[DOT]de>
		kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/
	    - x86-64, 部分i386, Andi Kleen <ak[AT]suse[DOT]de>
		ftp.firstfloor.org:/pub/ak/x86_64/quilt/
	
	  其他内核��树�以在http://git.kernel.org的列表中和MAINTAINERS文件里
	  找到。
	
	报告bug
	-------
	
	bugzilla.kernel.org是Linux内核开�者们用�跟踪内核Bug的网站。我们鼓励用
	户在这个工具中报告找到的所有bug。如何使用内核bugzilla的细节请访问：
		http://test.kernel.org/bugzilla/faq.html
	
	内核��主目录中的REPORTING-BUGS文件里有一个很好的模�。它指导用户如何报
	告�能的内核bug以�需��供哪些信��帮助内核开�者们找到问题的根�。
	
	
	利用bug报告
	-----------
	
	练习内核开�技能的最好办法就是修改其他人报告的bug。你�光�以帮助内核�
	得更加稳定，还�以学会如何解决实际问题从而�高自己的技能，并且让其他开�
	者感�到你的存在。修改bug是赢得其他开�者赞誉的最好办法，因为并�是很多
	人都喜欢浪费时间去修改别人报告的bug。
	
	��试修改已知的bug，请访问http://bugzilla.kernel.org网�。如果你想获得
	最新bug的通知，�以订阅bugme-new邮件列表（�有新的bug报告会被寄到这里）
	或者订阅bugme-janitor邮件列表（所有bugzilla的�动都会被寄到这里）。
	
		http://lists.osdl.org/mailman/listinfo/bugme-new
		http://lists.osdl.org/mailman/listinfo/bugme-janitors
	
	
	邮件列表
	--------
	
	正如上�的文档所�述，大多数的骨干内核开�者都加入了Linux Kernel邮件列
	表。如何订阅和退订列表的细节�以在这里找到：
		http://vger.kernel.org/vger-lists.html#linux-kernel
	网上很多地方都有这个邮件列表的存档(archive)。�以使用�索引擎�找到这些
	存档。比如：
		http://dir.gmane.org/gmane.linux.kernel
	在�信之�，我们强烈建议你先在存档中�索你想�讨论的问题。很多已�被详细
	讨论过的问题�在邮件列表的存档中�以找到。
	
	大多数内核�系统也有自己独立的邮件列表��调�自的开�工作。从
	MAINTAINERS文件中�以找到���题对应的邮件列表。
	
	很多邮件列表架设在kernel.org�务器上。这些列表的信��以在这里找到：
		http://vger.kernel.org/vger-lists.html
	
	在使用这些邮件列表时，请记���良好的行为习惯。下�的链接�供了与这些列
	表（或任何其它邮件列表）交�的一些简�规则，虽然内容有点滥竽充数。
		http://www.albion.com/netiquette/
	
	当有很多人回�你的邮件时，邮件的抄�列表会�得很长。请��将任何人从抄�
	列表中删除，除�你有足够的�由这么�。也���回�到邮件列表。请习惯于�
	一�邮件接收两次（一��自��者一��自邮件列表），而��试图通过添加一
	些奇特的邮件头�解决这个问题，人们�会喜欢的。
	
	记��留你所回�内容的上下文和�头。在你回�邮件的顶部�留“���说到……�
	这几行。将你的评论加在被引用的段�之间而��放在邮件的顶部。
	
	如果你在邮件中附带补�，请确认它们是�以直接阅读的纯文本（如
	Documentation/SubmittingPatches文档中所述）。内核开�者们�希望�到附件
	或者被压缩了的补�。�有这样�能��他们�以直接评论你的�行代�。请确�
	你使用的邮件��程��会修改空格和制表符。一个防范性的测试方法是先将邮件
	��给自己，然�自己�试是��以顺利地打上收到的补�。如果测试��功，请
	调整或者更�你的邮件��程�直到它正确工作为止。
	
	总而言之，请尊�其他的邮件列表订阅者。
	
	
	�内核社区�作
	----------------
	
	内核社区的目标就是�供尽善尽美的内核。所以当你�交补�期望被接�进内核的
	时候，它的技术价值以�其他方�都将被评审。那么你�能会得到什么呢？
	  - 批评
	  - 评论
	  - �求修改
	  - �求�明修改的必�性
	  - 沉默
	
	�记�，这些是把补�放进内核的正常情况。你必须学会��对补�的批评和评论，
	从技术层�评估它们，然��么�写你的补��么简明扼�地论�修改是�必�
	的。如果你�的邮件没有得到任何回应，请过几天��试一次，因为有时信件会湮
	没在茫茫信海中。
	
	你�应该�的事情：
	  - 期望自己的补���任何质疑就直接被接�
	  - 翻脸
	  - 忽略别人的评论
	  - 没有按照别人的�求�任何修改就�新�交
	
	在一个努力追寻最好技术方案的社区里，对于一个补�有多少好处总会有��的�
	解。你必须�抱��作的�度，愿�改�自己的观点�适应内核的风格。或者至少
	愿�去�明你的想法是有价值的。记�，犯错误是�许的，��你愿���正确的
	方案去努力。
	
	如果你的第一个补���的是一堆修改建议，这是很正常的。这并�代表你的补�
	�会被接�，也��味�有人和你作对。你�需�改正所有�出的问题然��新�
	�你的补�。
	
	内核社区和公�文化的差异
	------------------------
	
	内核社区的工作模��大多数传统公�开�队�的工作模�并�相�。下�这些例
	�，�以帮助你���些�能�生问题：
	  用这些�介�你的修改�案会有好处：
	    - 它�时解决了多个问题
	    - 它删除了2000行代�
	    - 这是补�，它已�解释了我想�说明的
	    - 我在5���的体系结构上测试过它……
	    - 这是一系列�补�用�……
	    - 这个修改�高了普通机器的性能……
	
	  应该��如下的说法：
	    - 我们在AIX/ptx/Solaris就是这么�的，所以这么�肯定是好的……
	    - 我�这行已�20年了，所以……
	    - 为了我们公�赚钱考虑必须这么�
	    - 这是我们的�业产�线所需�的
	    - 这里是�述我观点的1000页设计文档
	    - 这是一个5000行的补�用�……
	    - 我�写了现在乱七八糟的代�，这就是……
	    - 我被规定了最�期�，所以这个补�需�立刻被接�
	
	�外一个内核社区与大部分传统公�的软件开�队���的地方是无法�对�地交
	�。使用电�邮件和IRC�天工具�为主�沟通工具的一个好处是性别和��歧视
	将会更少。Linux内核的工作环境更能接�妇女和少数�群，因为�个人在别人眼
	里�是一个邮件地�。国际化也帮助了公平的实现，因为你无法通过姓��判断人
	的性别。男人有�能��丽，女人也有�能�王刚。大多数在Linux内核上工作过
	并表达过看法的女性对在linux上工作的�历都给出了正�的评价。
	
	对于一些�习惯使用英语的人�说，语言�能是一个引起问题的障�。在邮件列表
	中�正确地表达想法必需良好地掌�语言，所以建议你在��邮件之�最好检查一
	下英文写得是�正确。
	
	
	拆分修改
	--------
	
	Linux内核社区并�喜欢一下接收大段的代�。修改需�被�当地介��讨论并且
	拆分�独立的�段。这几乎完全和公�中的习惯背�而驰。你的想法应该在开�最
	开始的阶段就让大家知�，这样你就�以�时获得对你正在进行的开�的�馈。这
	样也会让社区觉得你是在和他们�作，而�是仅仅把他们当作倾销新功能的对象。
	无论如何，你��一次性地�邮件列表��50�信，你的补��列应该永远用�到
	这么多。
	
	将补�拆开的原因如下：
	
	1) �的补�更有�能被接�，因为它们�需�太多的时间和精力去验�其正确性。
	   一个5行的补�，�能在维护者看了一眼以�就会被接�。而500行的补�则
	   需�数个�时�审查其正确性（所需时间�补�大�增加大约呈指数级增长）。
	
	   当出了问题的时候，�的补�也会让调试�得�常容易。一个一个补�地回溯
	   将会比仔细剖�一个被打上的大补�（这个补�破�了其他东西）容易得多。
	
	2）�光���的补�很��，在�交之��新编排�化简（或者仅仅�新排列）
	   补�也是很��的。
	
	这里有内核开�者Al Viro打的一个比方：
		“想象一个�师正在给学生批改数学作业。�师并�希望看到学生为了得
		到正确解法所进行的�试和产生的错误。他希望看到的是最干净最优雅的
		解答。好学生了解这点，��会把最终解决之�的中间方案�交上去。�
	
		内核开�也是这样。维护者和评审者�希望看到一个人在解决问题时的�
		考过程。他们�希望看到简�和优雅的解决方案。
	
	直接给出一�的解决方案，和社区一起�作讨论尚未完�的工作，这两者之间似乎
	很难找到一个平衡点。所以最好尽早开始收集有利于你进行改进的�馈；�时也�
	��修改分�很多��，这样在整个项目都准备好被包�进内核之�，其中的一部
	分�能会先被接收。
	
	必须了解这样�是��接�的：试图将未完�的工作�交进内核，然��找时间修
	�。
	
	
	�明修改的必�性
	----------------
	除了将补�拆���，很��的一点是让Linux社区了解他们为什么需�这样修改。
	你必须�明新功能是有人需�的并且是有用的。
	
	
	记录修改
	--------
	
	当你��补�的时候，需�特别留�邮件正文的内容。因为这里的信�将会�为补
	�的修改记录(ChangeLog)，会被一直�留以备大家查阅。它需�完全地�述补�，
	包括：
	  - 为什么需�这个修改
	  - 补�的总体设计
	  - 实现细节
	  - 测试结果
	
	想了解它具体应该看起��什么，请查阅以下文档中的“ChangeLog�章节：
	  “The Perfect Patch�
	      http://www.zip.com.au/~akpm/linux/patches/stuff/tpp.txt
	
	
	这些事情有时候�起�很难。�在任何方�都�到完美�能需�好几年时间。这是
	一个�续�高的过程，它需�大�的�心和决心。���放弃，你一定�以�到。
	很多人已��到了，而他们都曾�和现在的你站在�样的起点上。
	
	
	---------------
	感谢Paolo Ciarrocchi�许“开��程�部分基于他所写的文章
	(http://linux.tar.bz/articles/2.6-development_process)，感谢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[AT]kroah[DOT]com>

• [ zh_CN ]
• CodingStyle
• HOWTO
• oops-tracing.txt
• sparse.txt
• stable_api_nonsense.txt
• stable_kernel_rules.txt
• SubmittingDrivers
• SubmittingPatches
• volatile-considered-harmful.txt
•