linux社区 如何参与到 Linux 社区中来

以前的导航:

补丁如何被接受

分段分支

器官

从上面提到的内核开发可以知道，整个内核开发过程都依赖于从各个方向有效集成补丁的能力。没有合适的、强大的工具，整个项目的合作大概就是空说说而已。关于如何使用这些工具的教程远远超出了本文的范围，这里只提供一些指导性的内容。

到目前为止，内核社区使用的主要源代码管理系统是git。Git是自由软件社区中开发的许多分布式版本控制系统之一。它非常适合内核开发，因为它擅长处理大型存储库和大量补丁。它也因难以学习和使用而闻名，尽管随着时间的推移它变得非常好。对于内核开发来说，掌握git是一项必要的技能，因为即使开发人员不把它用于日常的内核开发，最终也会面临与其他开发人员的同步问题，并入主干网。

Git已经集成到所有的Linux发行版中，它的官方网站是http://git-scm.com/.。这个网站有详细的文档和教程。此外，你可以参考http://linux.yyz.us/git-howto.html关于Linux内核的具体Git知识。在不使用git的内核开发人员中，最流行的选择几乎可以肯定是Mercurial:http://www.selenic.com/mercurial/, Mercurial和Git有很多相似的特性，但是在界面上使用更方便。

另一个值得推荐的工具是quiet:http://savannah.nongnu.org/projects/quilt/. quiet是一个补丁管理系统，不是一个源代码管理系统，不跟踪所有历史内容。相反，它根据不断发展的代码库跟踪一组特定的变化。一些主要子系统的维护人员使用Quilt来管理提交给上游的补丁。对于特定的树，(如-mm)面组可以高效地完成任务。

邮件列表

很多Linux内核开发工作都是通过邮件列表完成的。如果有开发者不加入任何邮件列表，ta一定是对社区成员了解不多。当然，邮件列表并不是一个完美的工具，至少它有两个缺点:大量的邮件信息吞噬着开发者；或者是违反了某些协议，有时甚至两者都违反。

大多数邮件列表在vger.kernel.org运行，主要的邮件列表在http://vger.kernel.org/vger-lists.html,，还有一些其他的列表，比如lists.redhat.com。

内核开发的核心邮件列表当然是linux内核。没见过世面的人看到这个榜单都会大吃一惊。每天能达到500多封邮件，大部分都是技术细节。正因为如此，讨论的参与者并不介意诸如礼貌之类的事情。但是没有其他地方可以将内核开发社区整合为一个整体；不订阅这个列表的开发者会错过很多重要信息。

以下是参与Linux内核邮件列表的一些提示:

将订阅列表单独放到某个目录下，不要显示在邮箱主界面。以在特定的时间段内毋须关注。不要试图去关注所有的话题 ———— 没有人能做到。重要的是过滤所关注的主题（尽管请注意长时间运行的对话可能会偏离原始主题而不更改电子邮件主题行）和参与的人。保持理智，如果有人在愤怒的情绪下争论，最好是忽略他们。当响应linux-kernel电子邮件（或其他列表上的电子邮件）时，保留所有涉及的Cc：所有参与者的。在没有强烈理由（例如显式请求）的情况下，永远不要去删除任何的收件人。始终确保回复的人员在抄送列表中。此约定还使得无需明确要求复制对帖子的回复。在提问之前，请先搜索邮件列表归档（以及Google网络）。一些开发人员可能会对那些显然没有完成作业的人感到不耐烦。要避免置顶情形（将自己的回答置于正在回复的引用文本之上的做法）。这么做会让人难以阅读，也会给人留下非常不好的印象。询问正确的邮件列表。

内核开发简介

关于如何启动内核开发过程的问题很常见，发起问题的既有个人也有公司。但是人往往没有耐心等别人的回答，开始工作，导致更严重的后果，还不如一开始什么都不知道。

企业找一些知名的开发人员来启动开发团队是惯例。其实这也是很有效的方法。但这往往是最昂贵的方法，对增加内核开发者数量没有直接影响。企业的另一个考虑是增加一些时间投入，让现有的内部开发人员参与Linux内核的开发。从长远来看，这笔投资是值得的，不仅可以培养一些对内核了解比较深的开发人员，还可以帮助、影响甚至培养更多的人。从中期和长期来看，这种方法最具成本效益。

对于个人开发者来说，往往会犹豫从何下手，这是完全可以理解的。从一个巨大的项目开始让人望而生畏，但我们可以试着从一些小的方面来解决它。比如一个好的起点是修复别人的拼写错误或者不重要的代码风格问题，但是需要提前向你声明这样的补丁会产生一定程度的噪音，会分散整个开发社区的注意力，所以越来越被人看不起。所以这样开始自己的内核开发之旅，并不能得到别人足够的认可。

安德鲁·莫顿为那些有兴趣成为Linux开发者的人提供了以下建议:

对于所有内核初学者来说，首要任务是“保证内核在所有能完成任务的机器上始终完美运行”。通常的做法是和别人一起解决问题(这可能需要坚持！)但是很好——是内核开发的一部分。

http://lwn.net/Articles/283982/

如果没有明显需要解决的问题，建议开发者查看当前回归列表和平均优先级的漏洞。要意识到，从来没有什么短期的、紧急的问题；通过解决这些问题，开发人员将在这个过程中获得经验，并在开发社区中建立对他人的尊重。

三

早期规划

当人们想象Linux内核开发项目时，可能会认为直接开始编码。其实Linux内核作为一个软件项目和其他项目没有什么不同，就是在写第一行代码之前，要做好充分的准备工作，这是所有软件项目成功的基本条件。在前期规划和沟通上花些时间，会让以后走路更轻松，节省更多时间。

01

清除问题

像任何工程项目一样，内核的成功是由于它对要解决的问题的清晰描述。在某些情况下，这是非常容易做到的:例如，当需要特定的硬件驱动程序时；但更多的时候，实际问题与人们所描述的相差甚远，往往导致更多的困难。

拿多年前的一个例子来说:Linux音频开发人员寻求一种方法来运行应用程序，而不会因为系统中的过度延迟而丢失或丢失其他内容。他们最初的解决方案是在音频的内核模块和Linux安全模块(LSM)之间做一个钩子，并配置这个模块来授权特定的应用程序访问实时调度程序。模块写好之后，发送到linux内核邮件列表，没多久就遇到问题。

对于音频开发人员来说，目前的安全模块足以解决他们的问题，但对于更广泛的内核社区来说，它被视为滥用LSM框架(不是授予他们原本不会拥有的进程特权)和系统稳定性的风险。内核社区认为首选的解决方案应该是短期内通过限制机制实现实时的预定访问，长期持续的延迟降低。

但是音频开发者并没有检查自己实现了什么，也不愿意接受替代方案；由此产生的差异让开发人员对整个内核开发过程感到失望。其中一人在音频邮件列表中发布了以下内容:

01

优秀的Linux内核开发者有很多，但是经常被一大群自大的傻子吓跑。把用户的需求传达给这些人是浪费时间。他们太自命不凡，根本听不进任何东西。

http://lwn.net/Articles/131776/

01

其实完全不是这样。内核开发人员更多关注的是系统稳定性、长期维护和找到问题的正确解决方案，而不是针对具体模块的具体解决方案。这个故事的寓意是关注问题本身——而不是具体的解决方案——并在实际投入代码工作之前尽可能多地与开发社区讨论。

在这里，我们给那些打算为内核做贡献的人以下建议:

究竟什么是需要解决的问题？该问题会波及到那些用户？解决问题应针对那些用例？当下的内核是如何解决该问题的？

只有回答完这些问题，才能考虑可能的解决方案。

02

早点讨论

在规划一个内核开发项目时，在开始实现之前与社区进行讨论是非常有意义的。早期沟通可以在许多方面节省时间和麻烦:

很有可能是目前内核的解决方式是开发者还没有理解，Linux 内核是一个非常大的项目，拥有非常多的功能和特性，而且它们往往并不是那么的明显，另外，并不是所有的功能都能文档化，而且还特别容易错过一些具体的功能，比如一位开发者看到一个发布的完整的设备驱动程序，该程序和现有的驱动程序重复了，而新的作者完全没有意识到。重新发明现有车轮的代码不仅浪费;它也不会被主干所接受。可能存在所提出的解决方案对于主干合是不可接受的因素。在编写代码之前最好找出这样的潜在问题。其他开发人员完全有可能考虑过这个问题;他们可能有更好的解决方案的想法，并可能愿意帮助创建该方案。

经过多年的内核开发，总结出一个非常有意义的教训:如果内核代码是在一个封闭的环境中设计和实现的，那么总会出现各种各样的问题，而这些问题只有发布到社区后才能被发现。有时会变得很严重，这些实现需要几个月甚至几年才能达到社区标准。这里有几个例子:

Devicescape网络堆栈是为单处理器系统设计和实现的。在它适用于多处理器系统之前，它无法合并到内核的主干当中，将锁定等改造成代码是一项艰巨的任务;因此，此代码（现在称为mac80211）的合并延迟了一年多。Reiser4 文件系统，自身包含了许多功能，这些功能在核心内核开发人员看来，很多已经在虚拟文件系统层中实现了，它还包括在不将系统暴露给用户导致的死锁的情况下无法轻松实现的功能。这些问题本身已经说明，更不用说开发者拒绝解决其中的一些问题，这明显导致 Reiser4 远离了主干。AppArmor 安全模块，被认为采用了不安全和不可靠的方式使用内部虚拟文件系统的数据结构。尽管后来代码进行了大幅的修改，但是离主干依旧很远。

以上案例都以惨痛的代价告诉我们，能节省很多时间，避免让人疯狂的痛苦经历，尽快与其他内核开发者沟通讨论。

03

你和谁谈过了

当开发者决定发布自己规划的内容时，接下来要做的是:从哪里开始？答案其实很简单:找到合适的邮件列表和合适的维护者。至于邮件列表，这就是我们前面提到的:最好的方法是在MAINTAINERS文件中查找它。如果文件中有对应的子系统列表，可以直接发邮件到地址，比在linux-kernel主列表中发送要好；因为有更大的机会接触到相应子系统中的相关开发者。

找到MAINTAINERS有点难。重要的事情说三遍，维护者文件就是一个好的开始。虽然这份文档有时不能及时更新，但甚至可能会发生这里根本没有提到某些子系统的情况。更有甚者，MAINTAINERS列出的人目前可能不再发挥任何作用。所以在对联系谁有疑问的时候，一个有用的技巧就是使用git(尤其是git日志)来查看当前的活跃情况。该命令可以查看谁编写了补丁，以及谁(如果有)将签名附加到了补丁上。这些人才是最适合帮助开发新项目的开发者。

如果你已经尝试了所有的方法，但是还是找不到相应的维护者，那就去找安德鲁·莫顿和他谈谈，这是追踪一个特定代码片段的维护者的有效方法之一。

04

什么时候提交？

尽早发布计划对内核开发者是有好处的。

伤害。描述正在解决的问题以及如何在计划中实施这些问题。换句话说，开发人员提供的任何信息都可以帮助开发社区。

其实事情可能出乎所有人的意料。在这个阶段，也就是开发者公开自己的方案的时候，可能令人沮丧的不是有人反对，而是很少有人甚至根本不理会。造成这种悲惨局面的可能原因是:

内核开发者真的都太忙了。规划写的过于”宏伟”，代码实现很少，这样的情况，多数开发者是不会搭理你的。没有人有义务或责任去审核其他开发者的提案的。

如果征求意见稿中几乎没有评论，请不要认为这意味着人们对项目不感兴趣。当然，你不能想当然地认为你的计划没有错。如果出现这种情况，最好的办法就是保持跟踪，与社区保持密切联系。

05

获得正式认可

如果开发人员的工作是在自己公司的环境下完成的(当然大部分Linux内核都是这样工作的)，显然还有一个重要的工作要做，就是在把公司的代码发布到公众邮件列表之前，要获得他公司的许可。在GPL兼容许可证下发布未清理的代码可能会导致问题；公司管理层和法务人员越早就核心开发项目的发布达成一致，对大家都有好处。

一些读者可能正在考虑使用他们的核心工作来支持尚未得到官方认可的产品。在公共邮件列表上公布雇主的计划可能不是一个好主意。出现这种情况，作者的建议是对公司保密。这不是我们通常意义上的闭门造车。我们应该注意它们之间的本质区别。

当然，有些公司在开发初期已经透露了自己的计划，不能关闭，所以有经验的内核开发人员的公司会选择开放开发，因为他们预见到集成问题会更严重。对于没有这种内部专业知识的公司来说，最好的选择是聘请外部开发人员根据保密协议对计划进行审查。Linux基金会有一个NDA项目，旨在帮助公司解决这种情况；更多信息可在以下网站找到:

http://www.linuxfoundation.org/en/NDA_program

这种审查通常足以避免未来出现严重问题，也没有必要公开披露公司的计划。

四

获取与代码相关的权利

虽然关于一个可靠的面向社区的设计过程有很多要说的，但最终证明事实的是代码本身。这里说的代码是指需要其他开发人员检查并合并(或不合并)到主干中的代码。所以这些代码很重要，直接决定了项目的成功与否。

这一节将向大家解释编码过程。首先，让我们来看看内核开发人员经常犯错误的链接，然后重点关注能够帮助完成任务的正确的事情和工具。

圈套

代码样式

Linux内核一直有一个相当标准的代码风格，在内核文档/编码风格中有描述。然而，大多数情况下，该文档更像是一个指南，而不是必须实施的。现实是内核中有很多代码不符合编码风格标准。这段代码的存在会给内核开发者带来两个不祥的征兆。

首先，那些认为内核的编码标准不再重要的人，他们认为没有必要强制执行。但其实这些人的代码如果不按照标准编码，在并入骨干的过程中会遇到很多困难。根据以往的观察，那些一开始不关注标准的人，都经历过这样的重新格式化过程。对于Linux内核这样的庞大项目，代码需要一些一致性要求，这使得开发人员可以快速理解任何部分，而不是把精力花在理解各种奇怪的“混乱风格”上。

当然，有时候内核的编码风格和开发者所在公司要求的编码习惯是冲突的。这时候如果想并入骨干仓库，公司需要做出妥协。将代码贡献给上游内核实际上意味着公司必须放弃一些东西，比如控制权——当然，这将包括代码的风格。

另一个常见的陷阱是主观认为内核中已有的代码存在风格问题，需要修复。开发人员可能会开始生成重新格式化的补丁来熟悉这个过程，或者将他们的名字添加到内核更改日志中，或者两者都添加。但是纯编码风格修复会被开发社区当成噪音；这种做法经常遭到冷遇。在处理功能性代码时，修复代码风格是一个自然的过程，但是代码风格的改变不应该提到与功能性相同的层次。

编码风格的文档不应该被视为绝对不可违背的定律。如果有很好的理由反对默认样式(比如一行分成80列，这一行的可读性会大大降低)，大胆去做。

抽象层

计算机专业的教授，在给学生讲课的时候，告诉大家尽量使用抽象。优点是更灵活，信息可以隐藏。当然Linux内核也大量使用抽象。使用这样一个数量级的代码而不进行抽象是不可想象的，但是经验表明，过度的或者过早的抽象可能和过早的优化一样有害。抽象应该使用到所需的级别。

在一个简单的层次上，考虑一个其参数总是被所有调用者传递到零的函数。人们可以保持这种观点，以防有人最终需要使用它提供的额外灵活性。但是到那时，实现这个额外参数的代码已经被一些从未被注意到的微妙方式破坏了——因为它从未被使用过。退一步说，当需要额外的灵活性时，它不会以满足程序员早期期望的方式完成。内核开发人员定期提交补丁，删除不用的参数；一般来说，默认情况下不应该添加。

隐藏访问硬件的抽象层——通常允许大量驱动程序用于多个操作——通常是一件令人头痛的事情。这些层会模糊代码，并可能导致性能损失；它们不应该属于Linux内核。

另一方面，如果你发现自己从另一个内核子系统中复制了大量代码，那么是时候问问把一些代码提取到一个单独的库中，还是在更高的层次上实现这个函数更有意义了。在整个内核中复制相同的代码没有任何价值。

Ifdef和预处理

有些C程序员因为C语言预处理器的强大功能停不下来。他们认为这是一种有效的方式，将许多灵活性编码到源文件中。但是预处理器毕竟不是C语言本身，预处理器的大量使用会使代码难以阅读，编译器也不容易查出来问题。使用预处理器的代码太多，需要重构。

使用#ifdef的条件编译确实是一个强大的功能，内核也经常使用，但是很少有人愿意看到ifdef覆盖的代码。所以内核团队的一般规则是尽量把ifdef的使用范围限制在头文件，有条件编译的代码可以限制在函数。如果代码不存在，这些函数是空。然后，编译器会默默优化对空函数的调用。这样代码会更清晰，更容易遵循。

c预处理器宏有很多危险，包括表达式多次求值的可能性，有副作用，没有类型安全。如果要定义宏，可以考虑创建一个内联函数。效果是一样的，只是内联函数比较好读，不会被评价很多次。它还允许编译器对参数和返回值执行类型检查。

内嵌函数

内联函数的使用也应该谨慎，开发人员可能会为了暂时的方便而放弃

使用函数调用，但是使用内联函数来填充源文件，目的是更快地完成工作。但是，这样做会影响性能。因为这些代码在每次函数调用中都会被复制一次，编译后的内核最后会变得非常大。反过来，这会给处理器的内存缓存带来压力，从而大大降低执行速度。基于此，内联函数应该很小，不鼓励频繁使用。毕竟函数调用成本不高；创建大量内联函数是过早优化的典型例子。

通常内核开发者会忽略缓存效应的危险。过去在数据结构课程中讲授的时间/空之间的经典权衡，在现代硬件设施中已不再适用。空是时间，所以大程序比紧凑程序慢。

锁

2006年5月，“Devicescape”网络栈准备高调进入主干网。基于GPL协议，这一捐赠在社区非常受欢迎，因为Linux从来没有完美支持过无线网络，Devicescape完全可以弥补这一点。但是，直到2007年6月，这段代码才真正进入主干网(2.6.22)。中间发生了什么？

Devicescape的代码基于封闭的开发模式，有很强的痕迹。最重要的一个问题是它不支持多处理系统。在这个网络栈(现在称为mac80211)可以合并到主干网之前，有必要修改锁定方案以支持多处理器。

曾几何时，Linux内核代码的开发不需要考虑多处理器所需的并发问题。但是，现在，这个文件写在双核笔记本电脑上。即使在单处理器系统上，提高响应能力的工作也会提高内核中的并发性。所以，那些不用考虑锁的编码的日子一去不复返了。

任何资源(数据结构、硬件寄存器等。)可以被多个线程同时访问的必须有锁保护。编写代码时考虑锁是默认的做法，尽管很难更改。内核开发人员应该花时间理解可用的锁定原语，以便为他们的工作选择正确的工具。目前缺乏对并发性关注的代码将很难进入主干。

返回

最后一个值得一提的危险是，它可能很容易改变(这可能带来很大的改进)，这会让现有用户无法使用。这种变化叫做“回归”，回归成为骨干内核中最不受欢迎的。除了少数例外，如果回归不能及时修复，导致回归的更改将被回滚。最好避免退货的问题。

人们往往认为，如果一次回报可以让事情对更多的人有用，只带来很少的问题，那么回报就是合理的。为什么能给十个系统带来新的功能，只有一个系统崩溃进行改进？Linus在2007年7月对这个问题给出了最好的答案:

我们不会通过引入新问题来修正错误。这种方式是疯狂的行为，因为没有人知道你是否真的取得了真正的进步。是前进两步后退一步，还是前进一步后退两步？

摘自(http://lwn.net/Articles/243460/)

一种特别不受欢迎的回归类型是ABI用户之间的任何类型的变化空。导出用户之间的接口空后，必须无限期支持。这一事实使得用户空之间接口的创建特别具有挑战性:因为它们不能以不兼容的方式进行更改，所以必须在第一时间完成。所以总是需要对用户之间的接口空进行大量细致的考虑，清晰的解释，大量的审核。

待续