如何加入Linux社区开发(译)二

5：发布补丁

或早或晚，总有一天，你的工作是准备提交给社区审查，并最终纳入到内核主线。并不奇怪，内核开发社区已经形成了一套公约和程序，用来发布补丁，遵循他们会让大家更容易参与。这份文件将试图在合理的细节上覆盖这些程序，更多信息也可以在内核文档目录中SubmittingPatches，SubmittingDrivers和SubmitChecklist找到。

5.1：什么时候发送

这有一个永恒不变的想法，在“完全准备好了”之前，避免发布补丁。对于简单的补丁，这不是一个问题。如果正在做的工作是复杂的，工作完成之前，这里有很多反馈需要从社区获得。所以，你应该考虑张贴你正在进行的工作，甚至建一个Git树可让有兴趣的开发人员在任何时候赶上你的工作。

张贴未考虑准备好的代码，在张贴本身，这是一个好主意。还可以提到任何仍然要做的主要工作，任何已知的问题。较少的人看这是已知的半生不熟的补丁，但那些带着这样想法的人，可以帮助你推动工作往正确的方向。

5.2：在创建补丁

考虑发送补丁到开发社区之前，这有一些事应该要做，这些事包括：

• 在您可以做到的范围内，测试你的代码。利用内核的调试工具，确保使用所有内核合理的配置选项组合，使用不同的架构等交叉编译器来构建。
• 确保你的代码与编码风格符合内核标准的指导方针。
• 你的改变是否影响性能？如果是，你应该运行benchmarks来显示你的变化的影响（或收益）的;测试结果摘要包括在补丁内。
• 要确保你有权限发布你的代码。如果这项工作是为雇主的工作，雇主可能对其有一个工作权利，都必须符合其在GPL许可证下发布。

作为一般规则，代码在发布前，把一些额外的想法说出来几乎总是可以在短期内的努力获得回报。

5.3：补丁的制作

发布补丁的准备是一个数量惊人工作，但无论如何，试图节省时间一般是可取的，即使在短期内。

修补程序必须对一个特定版本的内核准备。作为一般规则，补丁应基于在Linus的Git源码树中的目前的主线。它可能需要对-mm，Linux-next或一个子系统树的版本，进行更广泛的测试和审查。根据您的补丁区域和在其他地方正在发生的事情，基于对这些源码树补丁，需要大量的工作来解决冲突和API的变化问题。

只有最简单的修改应被格式化为一个单一的补丁，其它的应该作为一个系列更改补丁。分裂补丁是一门艺术;一些开发者花费很长的时间思考如何做是内核社区所期望的。

这里有一些规则，可以帮助我们考虑：

• 您发布的补丁系列，几乎可以肯定不会是你的版本控制系统中发现的一系列变化。您所做的更改需要考虑的最后形式，然后你的补丁分裂才有意义。开发者对离散的，独立的变更有兴趣，而不是你得到变化的这些路径。
• 每一个逻辑上独立的变动，应被格式化为一个单独的补丁。这些变化可以小（“添加字段到这个结构”）或较大（例如加入一个新的重要的驱动程序），但他们应该在概念上小，服从一个单行的描述。每个补丁应该做具体更改，可自行审查和核实其所说的更改。
• 作为上述指引的方式重申：不同类型的变化不要混合在同一个补丁。如果单个补丁修复了一个严重的安全漏洞，重新安排一些结构，并重新格式化代码，这将很有可能通过，重要的修补程序将丢失。
• 每一个补丁应该产生正常运行的内核，如果你的补丁系列是在中途被中断了，结果应该是仍然可以工作的内核。一个补丁系统的是一个常见的情况，“gitbisect”工具是用来寻找回归的，如果结果破坏了内核，你将让开发人员和用户陷入困境，他们正在做追踪问题的崇高工作。
• 但不要过分信赖于它。一位开发者最近公布了一组编辑为一个单独的文件修正500单个补丁－－这个行为，并没有使他在内核邮件列表上成为名人。单个补丁可以合理的大，只要它仍然是包含一个单一的逻辑改变。
• 这可能是很有诱惑力的一个补丁，将添加一系列全新的基础代码，但直到最后补丁并没有使能这个基础设施的整个工作，而无用地丢弃了。这种诱惑，应尽量避免使用，如果这一系列补丁增加了回归，另外将作一个最终的补丁修正这个问题，即使真正的错误是在其他地方。只要有可能，一个补丁增加了新的代码，其代码应立即激活。

努力创造完美的补丁系列可能是一个令人沮丧的过程，“真正的工作”要完成，需要相当多的时间思考。虽然做的很好，但这是非常花时间。

5.4：补丁格式化

因此，现在你有一个完美的补丁系列发布，但这项工作还没有做得相当好。每个补丁需要格式化为一个讯息，快速，清楚地表达其宗旨，以至世界各地。为此，每个补丁将组成如下：

• “From”选项，补丁程序的作者。如果你用在别人的补丁通过电子邮件传递，此行只是必要的，你可能有疑问，但添加它绝不会伤害到谁。
• ·“what the patch does”一行说明。在没有其他方面指出补丁的范围的条件下，此消息应该是足够让读者了解；这一行将显示在“short form”变更记录中。此消息通常被格式化如下，首先是相关子系统名称，然后是补丁目的。例如：

gpio: fix build onCONFIG_GPIO_SYSFS=n

• 紧跟着补丁内容的详细描述之后加一个空行。这个描述根据需要而添加，说明为什么补丁应用于内核。
• ·一个或多个标记线，至少由一人签署过：与补丁的作者一致。标签将会在下面详细描述。

以上三条应在为版本控制系统提交更改时正常使用。它们将遵从以下条目：

• 一个或多个标记线，至少由一人签署过：与补丁的作者一致。标签将会在下面详细描述。

以下正在修正翻译：

您应该避免不相干的文件包括更改的补丁（编译过程，例如，或编辑器生成的备份文件）。该文件“dontdiff”中的文件目录可以帮助在这方面，把它传给差异与“-X”的选项。

上面提到的标签是用来描述不同的开发商已与此相关的补丁开发。他们详细介绍了在SubmittingPatches文件;接下来这里是一个简短的总结。其中每一行的格式是：

标签：<电子邮件地址>可选的姓名，其他，东西

常用的标记是：

• 签名过由：这是开发商的认证，他或她有权提出到内核列入补丁。这是对开发商的原产地证书的全文可在文档/SubmittingPatches协定。没有正确的签收代码不能被合并到主线。
• Acked由：表示一个由另一个开发者（通常是相关的代码维护者），该补丁到内核中是适合列入协议。
• 测试由：国家，命名的人进行了测试，发现它的修补工作。
• 评论由：指定开发商已审阅正确性补丁;看到更详细审阅在文档/SubmittingPatches声明。
• 报告由：名用户是谁报告了这个补丁修复的问题，这种标签是用来给信贷的（常常被低估）人谁测试我们的代码，让我们知道，事情并没有正常工作。
• 抄送：指名的人收到了补丁的副本，并有机会对此发表评论。

在标签的除了你的补丁注意：只有抄送：是除了适当未经被点名的人的明确许可。

5.5：发送补丁

在你的邮件你的补丁，还有其他的几件事情你应该注意的：

• 你确定你的邮件将不会损坏补丁？其中有免费修补程序的空白进行更改或换行由邮件客户端将不适用在另一端，往往不会在任何详细的审查。如果有任何疑问的是，邮寄给自己的补丁，并说服自己，它就会显示完整。
  
  文档/电子邮件clients.txt对补丁进行发送邮件客户端工作的一些具体有用的提示。
• 你确定你的补丁是愚蠢的错误免费的吗？您应该始终贯穿脚本补丁/checkpatch.pl和处理投诉，想出。请记住，checkpatch.pl，而作为一个内核补丁应该是什么样子的思想相当数量的体现，是不是比你聪明。如果确定一个checkpatch.pl投诉将使代码更坏，就不要去做。

补丁应该始终发送纯文本。请不要将其作为附件发送，这使得它更难以评论引述在其答复修补部分。相反，只要把补丁直接将您的信息。

当邮件补丁，重要的是要抄送给任何人谁可能也感兴趣。不像其他一些项目，鼓励人们犯错误内核关于派遣太多副本一边，不承担有关的人会看到你的邮件列表上发布。特别是，应该去副本：

• 受影响的子系统（s）的维护者（s）。如前所述，维护人员文件是第一个地方去寻找这些人。
• 其他开发谁一直工作在同一地区-尤其是那些谁可能是在那里工作了。使用Git来看看还有谁修改了文件，你的工作是有帮助的。
• 如果你是在回答一个错误报告或功能的要求，将原始的海报以及。
• 发送一份拷贝到相关的邮件列表，或者，如果没有别的应用，Linux的内核名单。
• 如果你正在修复一个错误，想想是否修复程序应进入下一个稳定的更新。如果是这样，stable@kernel.org应该得到修补副本。还可以添加“抄送：stable@kernel.org”修补自身的标签内，这将导致稳定的团队获得通知当你进入了修正主线。

在选择收件人的补丁，这是好事，有一个你认为谁最终接受了补丁，并把它合并的想法。虽然可以直接发送给LinusTorvalds的补丁，让他把它们合并，事情通常不会做。莱纳斯忙，还有谁在维护子系统的内核的特定部分手表。通常你会希望合并是保持你的补丁。如果没有明显的维护者，安德鲁莫顿往往是最后补丁的目标。

修补程序需要良好的主题行。对于一个贴片线规范格式是这样的：

[补丁中性/毫米]子系统：一是网上描述的修补程序

其中“nn”是序数的补丁，“毫米”是系列中的斑块总数，而“子系统”是受到影响的子系统名。显然，神经网络/MM可以省略一个单一的，独立的补丁。

如果你有一个显着一系列的补丁，这是习惯的一部分发送零一介绍说明。该公约虽然是没有得到普遍遵循，如果你使用它，请记住，在引进信息不作变更记录到它的内核。所以，请确保该补丁，自己有完整的更新日志信息。

一般来说，一个多部分补丁的第二和以下部分应送交作为第一部分答复，使他们都在接收端线程在一起。像Git和被子工具有命令寄出用正确的穿线套补丁。如果你有一个漫长的系列，不过，并使用Gi​​t，请提供-无链的回复选项，以免造成极其深刻的嵌套。

6：FOLLOWTHROUGH

在这一点上，你遵循了迄今，并与自己的工程技术此外，准则，已经发布了补丁完美的系列。其中一个最大的错误，即使是有经验的内核开发人员可以得出这样的结论，是他们的工作是完成了。事实上，发布补丁表明，一场进入下一阶段过渡的过程，可能的话，但相当多的工作需要做一点。

这是一种罕见的补丁，那么在第一次张贴好，没有改进的余地。内核开发过程中认识到这一事实，作为一个结果，是严重朝着公布了代码，改善为主。你，作为该代码的作者，将有望与内核社区工作，以确保你的代码是由内核的质量标准。一个没有参加这一进程很可能以防止主线列入了你的补丁。

6.1：与审评

一个任何意义补丁将导致从其他开发商的意见，因为他们审查代码。与审评工作就可以了，对于许多开发商，内核开发过程中最令人生畏的一部分。生活可容易得多，不过，如果你一直在脑海中几件事情：

• 如果你有你的补丁以及解释，评审会明白它​​的价值，为什么你去了，写下这些麻烦。但是，该值将不能阻止他们提出一个根本性的问题：什么会是想维持与此代码在它的内核五年或十年后？许多您可能会被要求进行修改-从编码到大量的重写式的调整-从理解，Linux将依然存在和正在发展的十年是从现在开始。
• 代码审查是艰苦的工作，这是一个比较吃力不讨好的职业，人们还记得是谁写内核代码，但很少有持久的名声对于那些谁审查它。因此，评论者可以得到脾气暴躁，尤其是当他们看到同样的错误正在一遍又一遍。如果你得到一份评论，似乎生气，侮辱，或直接进攻，抵制的冲动回应。代码审查是关于代码，而不是对人，和代码的评论是不攻击你个人。
• 同样，代码评审是不是要促进各种自费雇主的议程。内核开发人员通常期望能够从现在的内核年的工作，但他们明白，他们的雇主可以改变的。他们真的是，几乎无一例外地朝他们可以创造最好的内核工作，他们是不是想为他们的雇主的竞争对手不适。

什么这一切归结起来就是，当你发送评论意见，需要注意的是他们正在技术性意见。不要让自己的表达形式，或你自己的骄傲让这种情况发生。当你对一个补丁审查意见，需要时间去了解什么Reviewer是想说什么。如果可能的话，修复的东西，审阅要求你解决。并响应回审稿：感谢他们，并描述你将如何回答他们的提问。

请注意，你不必同意评论者建议每一个变化。如果您认为您的代码审阅误会，解释什么是怎么回事。如果您有技术异议，建议改变的话，描述和证明你解决问题。如果你的解释是有意义的，愿意接受他们的检阅。如果你不能证明有说服力的解释，虽然，特别是如果有人开始同意审阅，需要一些时间来考虑再三的事情。它可以很容易成为自己的解决方案给到如此地步，你不知道什么问题是根本错误的蒙蔽，或许，你甚至不正确的问题解决。

一个致命的错误是忽视，希望他们会自行消失审查意见。他们不会消失。如果您无需重新发布作出的评论你有时间代码之前，你可能会发现你的补丁没有出路。

谈到重新发布代码：请记住，评论不会记住所有的代码，你最后一次公布了细节。因此，它始终是一个好主意，提醒先前提出的问题以及如何处理的评论与他们联系，补丁更新日志是这类信息的好地方。审稿人不应该通过列表档案搜索熟悉什么是自己最后一次说，如果你帮助他们获得一个良好的开端，他们将在一个好心情，当他们重新审视你的代码。

如果你一直在努力，尽一切事情的权利，仍然是不会去任何地方？大多数技术的分歧可以通过讨论加以解决，但有些时候，当有人根本作出决定。如果你真的相信，这一决定是对你会错，你随时可以尝试吸引到一个更高的权力。在撰写本文时，高功率往往是安德鲁莫顿。安德鲁在内核开发社区非常尊重，他往往能unjam这种情况似乎是无可救药地阻止。呼吁安德鲁不应该做的掉以轻心，但是，没人在所有其他办法进行探讨。并铭记，当然，他可能不同意你的意见或者。

6.2：接下来会发生什么

如果补丁被认为是一件好事添加到内核，一旦检讨大部分问题已经得到解决，下一步就是通常分为一个子系统的维护者的树条目。如何从一个不同的工作到下一个子系​​统，每个维护者他或她的处事方式。特别是，可能有一个以上的树-一个，也许，专门为长期工作，今后计划合并窗口补丁，另一个。

申请的领域修补程序不存在任何明显的子系统树（内存管理补丁，例如），默认的树往往最终被毫米。修补程序，影响多个子系统同时也可以通过毫米树去。

成树共享子系统可以带来更高的知名度水平提升到一个补丁。现在，与该树工作的其他开发人员将获得由默认补丁。子系统通常饲料以及树木成毫米和Linux的未来，使他们的内容可以看到整个开发社区。在这一点上，有一个很好的机会，你会得到一组新的评论更多的意见，这些意见需要回答在上一轮。

什么也可能发生在这一点上，这取决于你的补丁的性质，是与工作的冲突被别人出场完成。在最坏的情况下，重补丁的冲突可能会导致一些被搁置的背面，使其余的补丁可以合并成形状和加工工作。其他时候，冲突的解决将涉及正与其他开发人员，可能还有一些树木之间移动补丁，以确保一切适用干净。这项工作可以是一个痛苦的，但想想你的祝福：前Linux的下一个树的到来，这些冲突往往只出现，在合并窗口，不得不在匆忙解决。现在，他们可以解决，休闲，合并前的窗口打开。

有一天，如果一切顺利的话，你就会登录并看到你的补丁已经被合并到主内核。恭喜！一旦庆祝完成（而且您已将自己的维护者文件），虽然，这是值得记住的重要一点事实：仍然没有完成任务。进入主线合并给自己带来的挑战。

首先，你的补丁再次能见度提高。有可能是从开发商谁没有意识到的补丁之前，新一轮的意见。这可能是很有诱惑力的忽略他们，因为不再有任何问题，你的代码被合并。抵制这种诱惑，虽然，你仍然需要向开发商谁反应有问题或建议。

更重要的是：进入主线列入放到一个更大的群体测试者手中你的代码。即使你有一个硬件的贡献尚未提供驱动程序，你会惊奇地发现有多少人将建设成为他们的内核代码。当然，哪里有测试，就会有错误报告。

报告的BUG最坏的回归。如果你的补丁会导致回归，你会发现你的眼睛不舒服时数;回归必须尽快修复。如果您不愿意或无法修复的回归（而不是别人为你做它），你的补丁几乎肯定会被删除，在稳定期。除了否定你所做的让你把所有的工作主线补丁，有一个修补程序，出现故障修复一拉回归结果很可能使你更难获得在将来合并的工作。

回归后，任何已经处理了，可能还有其他，普通的错误处理。稳定期是你最好的机会来修复这些错误，确保你的代码在主线内核发布处女作是尽可能稳固。因此，请回答错误报告和解决这些问题，如果在所有可能的。这就是稳定期为，你可以开始创建一旦与旧的任何问题，很酷的新修补程式已被照顾。

而且不要忘记，还有其他的里程碑这也可能造成错误报告：未来主线的稳定版本，当突出的经销商拿起一个包含你的补丁的内核，版本等继续为应对这些报告是一个基本问题你的工作感到自豪。如果这是不够的动机，但是，它也值得考虑，发展社区记得开发商谁失去兴趣后，他们的代码的合并。下次您发布了一个补丁，他们将评估的假设，你将不在周围，以维持它在那之后。

6.3：其他事情都有可能发生

有一天，你可能会打开你的邮件客户端，看到有人寄给您对您的代码补丁。这是有你的代码在那里毕竟在开放的优势之一。如果您对补丁同意，可以将其转发到该子系统的维护者（一定要包括适当者：列，这样的归属是正确的，并添加你自己的签收），或发送Acked由：反应回来，让原始的海报发送向上。

如果您不同意与修补程序，发送一个礼貌的回应，解释原因。如果可能的话，告诉笔者需要什么样的变化必须作出修补，使你可以接受的。有一定的阻力合并是由作者和维护者反对的代码的补丁，但只去这么远。如果你被视为不必要的阻塞良好的工作，这些补丁最终将进入绕流，你无论如何得主线。在Linux内核中，没有人拥有绝对否决权的任何代码。也许除了莱纳斯。

在非常难得的机会，你可能会看到完全不同的：另一个开发者发布了一个不同的解决您的问题。在这一点上，很有可能两个补丁便不会被合并，“我先来的”不认为是一个令人信服的技术参数。如果别人的修补程序取代了你，进入主线得到，但实际上只有一个办法回应：很高兴您的问题得到有效解决，而且能和你的工作。有自己的工作推一边以这种方式可以伤害和沮丧，但社会会记住你的反应后不久就忘记了他的补丁到底是怎么合并。

7：高级主题

在这一点上，希望你有一个关于如何处理发展过程中的作品。还有更多的学习，但是！本节将涉及的话题，可对于希望成为Linux内核开发过程中的常规组成部分开发商有帮助数。

7.1：使用Git驾驭斑

该内核的分布式版本控制的使用开始于2002年初，当Linus首次开始与专有的BitKeeper应用玩耍。虽然BitKeeper的是有争议的，软件版本管理方法，它体现肯定不是。分布式版本控制使一个内核开发项目的直接加速。在当今时代，有几个是BitKeeper的免费替代品。不论是好是坏，内核项目作为其首选工具git的解决。

使用Git管理补丁可以让生活变得更容易为开发商，尤其是因为这些补丁数量增加。Git的也有其粗糙的边缘，并造成一定的危害，它是一个年轻而强大的工具，它仍在其开发文明。这个文件不会试图教导读者如何使用Git，这将是一个在自己的权利很长的文件足​​够的材料。相反，这里的重点将放在如何把git的开发过程中符合特定的内核。开发商谁愿意来加快速度与Git会找到更多信息：

http://git.or.cz/

http://www.kernel.org/pub/software/scm/git/docs/user-manual.html

以及不同的教程在网上找到了。

业务的第一步是阅读上述地点，并获得如何Git的作品，然后再尝试用它来制作补丁提供给他人扎实的理解。一个Git-使用开发人员应该能够获得一个主线档案库，探索修订历史记录，提交到树木的变化，用树枝等的一个Git的工具改写历史（如变基）的理解也有用。Git的带有自己的术语和概念;一个Git的新用户应了解参，远程分支机构，索引，快进合并，推和拉，独立负责人等，都可以在一开始就有点吓人，但这些概念并不难掌握的学习与位。

使用Git来产生通过电子邮件提交补丁可以是一个很好的锻炼，而即将到来的速度。

当您准备开始把注册从Git树木拉别人看时，你会，当然会需要一个服务器，它可以。设置的git- daemon的这样一个服务器的，是相对简单，如果你有一个系统，可以访问互联网。否则，自由，公共托管网​​站（Github上，例如）开始出现在网上。成立开发人员可以获取有关kernel.org一个帐户，但这些都不是来之不易的，见http://kernel.org/faq/获取更多信息。

Git的正常工作流程涉及到很多的分支机构使用。每个发展路线可以分为一个单独的“主题分支”，保持独立。Git中科很便宜，也没有理由不把他们都免费使用。而且，在任何情况下，你不应该做任何一个分支，它在你打算请别人来从你的发展。公开发表的分支机构应建立与关怀，在补丁开发分支合并到当他们在填写表格，并准备去-不前。

Git的提供了一些有用的工具，可以让你重写你的发展史。不方便的修补程序（一，打破平分，也就是说，或有一些明显的错误其它排序）可固定在地方或从历史作出完全消失。补丁系列可改写为如果它已在今天的主线上编写的，即使你已经在它的工作了几个月。变化可以透明地转移到另一个从一个分支。等等。Git的能力修改历史可以帮助创造清洁明智地使用补丁套，少的问题。

这种功能的过度使用会导致其他问题，虽然，超越了完美的项目创造历史的简单的痴迷。改写历史将改写这一历史中的变化，变成一个未经考验的一个一个测试（希望）内核树。但是，除此之外，开发商不能容易地合作，如果他们没有一个项目的历史认同的看法，如果你改写历史，其他开发人员在其仓库拉，你就会让生活更适用于那些开发困难。因此，一个简单的经验法则适用于这里：历史，已出口到其他人一般应为永恒不变之后看到。

所以，一旦你推到您的公开可用的服务器更改设置，这些变化不应该被改写。Git会尝试执行这项规则，如果你努力推动的改变，不会导致在快速向前合并（即不改变共享相同的历史）。它可以覆盖此检查，并有可能有时是要重写一个导出树。变更集之间移动的树木，以避免在Linux的未来冲突就是一个例子。但是，这种行动应该是罕见的。这是为什么发展工作应在私营部门（可重写如有必要），只有在公共部门转移时，在一个相当发达的国家的原因之一。

作为主线（或其他树木的变化形成一个集计算）的进步，这是很有诱惑力的合并，该树留在领先的优势。对于一个私有分支，重订基期可以是一个简单的方法来保持与另一棵树，但不是一种选择重订一次，树是出口到世界各地。一旦出现这种情况，一个完整的合并必须做到的。合并偶尔有其意义，但过于频繁的合并可以不必要混乱的历史。在这种情况下建议的方法是合并很少，一般只在特定发布点（如主线-RC版本）。如果您对具体变化的紧张，你可以随时进行测试在私有分支合并。GIT的“rerere”工具可在这种情况下非常有用，它记得合并冲突得到解决，这样你就不用做同样的工作两次。

关于喜欢的Git工具最大的经常性的抱怨之一是这样的：从一个群众运动的补丁仓库到另一个可以轻松地滑不明智的改变，到下面去检讨雷达主线。内核开发者往往会得到不愉快的，当他们看到这种事情发生的种类;搭一个Git树，未审核或偏离主题的补丁可能会影响你的能力在未来得到拉树。竞标莱纳斯：

你可以给我的补丁，但我拉你一个Git从补丁，我需要知道你知道自己在做什么，我需要能够信任而不*然后不必去检查每一个人的事情*手动更改。

（http://lwn.net/Articles/224135/）。

为了避免这种情况，确保在某一分支所有补丁坚持密切相关的话题，一个“驱动修复”分行不应该作出改变，核心内存管理代码。而且，最重要的是，不要使用一个Git树绕过审查过程。张贴的规定向有关名单树，而且，当时间是正确的，要求该树在Linux的未来，包括偶尔的总结。

如果当别人开始发送到你的树列入补丁，不要忘了审查。还要确保你保持正确的著作权信息;GIT的“我”的工具，并在这方面的最好的，但您可能需要添加一个“从：”行的修补程序如果它已通过第三方转达给你。

当要求一拉，务必给所有有关的资料：在你的树是什么科拉，和什么样的变化会导致拉。GIT的请求拉命令可以在这方面有所帮助，它会像其他开发商的格式要求的期望，也将检查以确保您记住，推动这些变化的公共服务器。

7.2：审查补丁

有些读者肯定会反对将与“高级主题”的理由，即使开始的内核开发人员应审查补丁本节。诚然，有没有更好的方式来学习如何在内核编程环境比其他人在看代码发布。此外，评论永远供不应求;由AT看代码，你可以作出重大贡献，作为一个整体过程。

审查代码可以是一个可怕的前景，特别是对于一个新的内核开发谁可能会感到紧张代码质疑-在公共-这已经被更有经验的张贴。即使最有经验的代码开发人员编写能够得到改善，但。也许，对于审评（所有评论）的意见最好的一块是这样的：作为问题，而不是批评短语审查意见。问：“如何锁定在这条道路获得释放？”将始终工作比指出更好“锁定在这里是错误的。”

不同的开发商将审查从不同的角度代码。有些人最关心的编码风格和代码行是否有尾随的空白。其他人将主要集中于是否作为一个整体补丁实施的更改是为内核或不好的事情。还有一些人将检查有问题的锁，过多的堆栈使用，可能的安全问题，在其他地方重复代码，充足的文件，对性能产生负面影响，用户空间的ABI的改变等所有类型的审查，如果他们将带来更好的代码到内核​​，都欢迎和值得的。

8：更多信息

有对Linux内核的开发及相关主题的大量信息来源。首先在这些文件将永远是内核源代码目录中的分布发现。顶层HOWTO的文件是一个重要的出发点;SubmittingPatches和SubmittingDrivers也是一些东西，所有的内核开发人员阅读。许多内部的内核API都记录使用kerneldoc机制，“让htmldocs”或“使pdfdocs”可用于生成HTML或PDF格式的文件格式（虽然有些版本的TeX发行运到内部运行的限制，未能处理正确的文件）。

各种网站的详细讨论内核各级持续发展。你想虚心笔者建议http://lwn.net/作为源;主题的信息在许多特定的内核可以通过索引找到LWN内核在：

http://lwn.net/Kernel/Index/

除此之外，为内核开发价值的资源是：

http://kernelnewbies.org/

有关Linux的下一个树聚集在：

http://linux.f-seidel.de/linux-next/pmwiki/

当然，我们不应该忘记http://kernel.org/，发布权威信息的核心位置。

有一个内核开发的书籍数量：

Linux设备驱动程序，第3版（乔纳森科比特，亚历山德罗Rubini和GregKroah - Hartman的）。在网上http://lwn.net/Kernel/LDD3/。

Linux内核开发（罗伯特爱）。

深入理解Linux内核（丹尼尔马哥Cesati博韦和）。

这些书籍都患上了常见的故障，但：他们往往是他们打的时候有点陈旧的货架，他们已经在货架上一段时间了。尽管如此，仍有相当多的好信息位在那里找到。

对于git的文档可以在这里找到：

http://www.kernel.org/pub/software/scm/git/docs/

http://www.kernel.org/pub/software/scm/git/docs/user-manual.html

9：结论

恭喜任何人谁已经通过这个长篇大论文档。但愿它提供了如何在Linux内核开发以及如何参与这一进程可以帮助理解。

最后，它是参与的事项。任何开源软件项目是没有什么比它的贡献者投入到IT的总和。Linux内核工作进展迅速和以及它，因为它已经被一个开发商，他们都正在努力使之更好地帮助了一大批令人印象深刻。内核是一个什么样的可以做的工作时，数千人朝着一个共同的目标一起总理的例子。

内核总是可以受益于一个更大的开发基地，但。总是有更多的工作要做。但是，同样重要的，在Linux生态系统大多数其他参与者可以通过促进利益的内核。涉足主线代码是更高的代码质量，降低维护和分销成本，更高的影响力在水平方向的内核开发，更关键。这是每个人都参与的情况下获胜。启动你的编辑和加入我们，你会更受欢迎。