how_to_linux_kernel_development.txt

基于LINUX操作系统下的各种详细配置（如FTP

git树：
- Kbuild 开发树, Sam Ravnborg <[e-mail]>
kernel.org:/pub/scm/linux/kernel/git/sam/kbuild.git

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

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

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

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

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

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

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

- 网络驱动, Jeff Garzik <[e-mail]>
kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git

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

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

其他git内核树可以在http://kernel.org/git找到

quilt trees:
- USB, PCI, Driver Core, and I2C, Greg Kroah-Hartman <[e-mail]>
kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/

报告Bug
------

bugzilla.kernel.org是Linux内核开发者追踪内核bug的地方。我们鼓励用户在这个工具中报告他们发现的所有bug。欲知使用内核bugzilla的具体细节，请看：
http://test.kernel.org/bugzilla/faq.html

主内核源码目录中的REPORTING-BUGS文件有一个报告可能有的内核bug的模板，并详细讲述了内核开发者需要什么样的信息，以便他们可追踪到问题所在。

邮件列表
------

就像上面的一些文档所描述的，大多数核心内核开发者参与Linux内核邮件列表的讨论。如何订阅和取消订阅这个列表的细节可以从这里找到：
http://vger.kernel.org/vger-lists.html#linux-kernel
网上很多地方都有这个邮件列表的存档。使用一个搜索引擎来搜索这些存档。比如：
http://dir.gmane.org/gmane.linux.kernel
强烈建议你在向列表发邮件询问之前，先在存档中搜索一下你想问的话题。很多事情都已经详细的讨论过了，它们只在邮件列表存档中有记录。

很多内核子系统也有它们单独的邮件列表，在那里开发者们做他们的开发工作。请查看MAINTAINER文件来找到这些不同子系统的邮件列表。

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

请记住在使用这些列表时请遵守良好的行为习惯。下面的URL有一些如何在邮件列表上与人交流的简单的准则，虽然有一点俗气：
http://www.albion.com/netiquette

如果有许多人回复你的邮件，收件人的抄送列表会变得很长。在没有一个合理的理由时不要把任何人从抄送列表中去掉，或者不要只回复被列出的地址。要对于收到同一封信两次感到习惯，一次从发信者，一次从邮件列表。不要为了好看而加上别致的邮件头部，人们不喜欢这样。

记得保证你的回复的上下文和属性的完整性，在你的回复的最上方保留类似“John Kernelhacker wrote ...“的字样，把你的回复写在被引用的段落之间，而不要写在邮件的最上方。

如果你在你的邮件里加入了补丁，要确保它们是纯文本，就想Documentation/SubmittingPatches里所说的。内核开发者不希望处理附件或者压缩的补丁；他们会希望评价你的补丁的每一行，只有纯文本才符合这个要求。确保你使用的邮件客户端软件不会破坏空格和制表符。你可以发一个邮件给你自己，然后应用你自己的补丁来先做个测试。如果不行，修复你的邮件程序或者换一个。

最重要的一点，请记得显示出你对其他订阅者的尊重。

和社区一起工作
-----------

内核社区的目标是提供可能提供的最好的内核。当你提交了一个补丁等待被收录时，它会被且仅被该领域的技术权威所检查。所以，你应该期待什么呢？
－ 批评
－ 评论
－ 被要求改动
－ 被要求解释
－ 沉默

记住，这是让你的补丁进入内核的一部分。你必须能够接受对你的补丁的批评和评论，在技术的层面上评估它，然后要么对你的补丁作出修改，要么提供清晰而言简意赅的理由解释为什么不应该做改动。如果没有对你的补丁的回复，等几天再试一次，有时候在流量很大的时候信件可能丢失，或被人忽略遗忘了。

你不应该做什么：
－ 期待你的补丁没有任何疑问的被接受
－ 不接受批评，不承认缺点
－ 忽略评论
－ 在不做任何修改的情况下再次提交补丁

在一个寻找可能存在的最好的技术解决方案的社区里，关于一个补丁怎样的有用必定会存在不同的意见。你应该采取合作的态度，愿意改变你的意见以适应内核的需要。或者至少愿意证明的你的观点有价值。记住，犯错误是可以接受的，只要你愿意朝着正确的解决方案努力。

如果对于你的第一个补丁的回应只是一些要求你改正的意见，这很正常。这并不意味着你的补丁将不会被接受，这些意见也不是针对你本人的。你要做的只是改正你的补丁然后重新发送。

内核社区和企业架构的区别
-------------------

内核社区和大多数传统的企业开发环境工作形式不一样。这里有一个列表你可以尝试遵照执行以避免出现问题：
关于你提交的补丁的好的说法：
－ “这个可以解决多个问题。”
－ “这个删除了2000行代码。”
－ “这个补丁解释了我尝试想描述的东西。”
－ “我在5个不同的架构上测试了它……”
－ “这里是一系列的小补丁，它们可以……”
－ “这个在典型的机器上可以提高表现……”

你应该避免的坏的说法：
－ “我们在AIX/ptx/Solaris上都是这样做的，所以它一定是好的……”
－ “我已经这样做20年了，所以……”
－ “我的公司需要这样做来挣钱”
－ “这是我的一千页的设计文档，它解释了我的想法”
－ “我已经在它上面花了6个月的心血……”
－ “这里是一个5000行的补丁，它……”
－ “我重新写了所有现有的垃圾，在这里……”
－ “我有完成期限，这个补丁必须现在被应用。”

内核社区和大多数传统软件工程工作环境的另一个不同是没有面对面的交流。使用email和irc作为主要交流形式的好处之一是不会存在基于性别或者种族的歧视。Linux内核工作环境接受女士和少数民族，因为你的存在只是一个email地址。国际化也帮助我们实现了平等的工作环境，因为你无法根据一个人的名字来判断一个人的性别。一个男人可以叫Andrea，一个女人可以叫Pat。大多数为Linux内核做过工作或者发表过观点的女性对此都深有体会。

对于不习惯英语的人来说语言障碍可能会导致一些问题。对于语言的良好的掌握可以令思想在邮件列表上交流的更畅通，所以建议你在发送邮件之前检查一下你的邮件内容在英语里是否有意义。

打散你的补丁
---------

Linux内核社区不乐意接受大段的代码，一般会在收到时立刻丢弃。你的补丁需要适当的被介绍，讨论，并打散为细小的，独立的片段。这几乎和公司里经常做的完全背道而驰。你的提议必须在开发流程的早期提出，这样你才可以收到足够的关于你的工作的回馈。这也会令社区感觉到你是在和他们一起工作，而不是利用他们作为倾倒你的补丁的场所。但是，请不要一次向邮件列表发送超过50封email，你的一系列补丁的个数应该永远小于这个数字。

把补丁打散的理由如下：

1) 小的补丁增加了你的补丁被应用的机会，因为它不需要花太多的时间和 精力来检查它的正确性。一个5行的补丁，一个维护者只要花一秒钟瞟一眼然后就可以应用了。不过，一个500行的补丁需要一个小时来检查是否有错误（所需的时间跟补丁的大小差不多成指数级别增长）。

小补丁也使得在出错的时候很容易debug。如果出了问题，小补丁可以一个一个的取消，大补丁就比较麻烦了。
2) 除了要把补丁打散之外，在提交之前还要重写和简化（或者只是简单的重排序）你的补丁。这一点也是很重要的。

这里有一个内核开发者Al Viro所做的类比：
“想一下一个老师为一个数学系学生批改作业的情景。老师不希望看到学生在回答出正确答案之前的尝试和失败。他们想看到最清楚的，最优美的答案。一个好学生了解这一点，并不会在得到最终答案之前把他们的中间结果提交上去。

对于内核开发来说同样是这样。维护者和评论者不希望看到问题的解决方案背后的思考过程。他们想看到一个简单和优美的解决方案。”

提供一个优美的解决方案和同社区一起工作讨论你未完成的作品，要维持此二者之间的平衡可能是一个很有挑战性的事情。所以应及早的参与一个开发流程以获得回馈来改进你的作品，但仍要保证你的补丁的小块头，这样它们可能提早被接受，哪怕是在你的整个作品还为完成时。

也请注意，如果你的补丁尚未完成而且还需要修改，请不要提交。

证明你的改动
---------

除了打散你的补丁之外，让Linux社区理解为什么他们要加入这项改动也是很重要的。新的功能必须要被证实它们需要而且有用。

为你的改动写文档
-------------

在你提交补丁时，要格外留心你在email里说的话。这些信息将会成为这个补丁的ChangeLog信息，将会被保留从而使每个人任何时候都可以看到。它必须完整的描述这个补丁，包括：
－ 为什么这个改动是需要的
－ 这个补丁的整体设计方案
－ 实现细节
－ 测试结果

欲知这个过程到底看起来是什么样子的，请看这个文档的ChangeLog部分：
“The Perfect Patch”
http://www.zip.com.au/~akpm/linux/patches/stuff/tpp.txt




所有这些事情有时候很难做到。要想完美做到这些要求可能需要几年的时间。这是一个持续的发展过程，需要很多耐心和决心。但是不要放弃，这是可以实现的。很多人已经做到了这一点，每个人都经历过你现在这个阶段。



-------------
感谢Paolo Ciarrocchi允许我在他所写的文章的基础上写成本文的“开发流程”部分，感谢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]>