howto

linux 内核源代码

中的改动。

-mm版内核没有固定的发布周期，但是通常在每两个-rc版内核发布之间都会有若干
个-mm版内核发布（一般是1至3个）。


子系统相关内核源码树和补丁集
----------------------------
相当一部分内核子系统开发者会公开他们自己的开发源码树，以便其他人能了解内
核的不同领域正在发生的事情。如上所述，这些源码树会被集成到-mm版本内核中。

下面是目前可用的一些内核源码树的列表：
  通过git管理的源码树：
    - Kbuild开发源码树， Sam Ravnborg <[e-mail]>
	git.kernel.org:/pub/scm/linux/kernel/git/sam/kbuild.git

    - ACPI开发源码树, Len Brown <[e-mail]>
	git.kernel.org:/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6.git

    - 块设备开发源码树, Jens Axboe <[e-mail]>
	git.kernel.org:/pub/scm/linux/kernel/git/axboe/linux-2.6-block.git

    - DRM开发源码树, Dave Airlie <[e-mail]>
	git.kernel.org:/pub/scm/linux/kernel/git/airlied/drm-2.6.git

    - ia64开发源码树, Tony Luck <[e-mail]>
	git.kernel.org:/pub/scm/linux/kernel/git/aegl/linux-2.6.git

    - ieee1394开发源码树, Jody McIntyre <[e-mail]>
	git.kernel.org:/pub/scm/linux/kernel/git/scjody/ieee1394.git

    - infiniband开发源码树, Roland Dreier <[e-mail]>
	git.kernel.org:/pub/scm/linux/kernel/git/roland/infiniband.git

    - libata开发源码树, Jeff Garzik <[e-mail]>
	git.kernel.org:/pub/scm/linux/kernel/git/jgarzik/libata-dev.git

    - 网络驱动程序开发源码树, Jeff Garzik <[e-mail]>
	git.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git

    - pcmcia开发源码树, Dominik Brodowski <[e-mail]>
	git.kernel.org:/pub/scm/linux/kernel/git/brodo/pcmcia-2.6.git

    - SCSI开发源码树, James Bottomley <[e-mail]>
	git.kernel.org:/pub/scm/linux/kernel/git/jejb/scsi-misc-2.6.git

  使用quilt管理的补丁集：
    - USB, PCI, 驱动程序核心和I2C, Greg Kroah-Hartman <[e-mail]>
	kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/
    - x86-64, 部分i386, Andi Kleen <[e-mail]>
	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 <[e-mail]>