如何加入Linux内核开发社区(3)

本文翻译自The Linux Foundation的《How to Participate in the Linux Community》(基于2012-03-21最新版本)，原作者为Jonathan Corbet(corbet@lwn.net)。下面是该文章第三章节的中译文。

3、早期规划

当考虑一个Linux内核开发项目时，人们可能很想尽快投入并开始编码。但和任何重要的项目一样，推动项目成功的大量基础工作需要在第一行代码编写之前被精心安排好。一些在早期计划和沟通阶段所花费的时间可能在后期为你节约更多的时间。

3.1、明确问题

和任何工程项目一样，一次成功的内核改进都始于对所要解决问题的清晰描述。在某些情况下，这一步很简单：例如，当需要一块特定硬件的驱动程序时。但在其他情况下，人们很可能把真正的问题与提议的解决方法混为一谈，这将带来更多麻烦和困难。

考虑一个例子：几年前，Linux音频开发者试图找到一种方式使得音频应用在运行时不会因系统过分延迟而导致丢帧或其他人造干扰。在他们给出的解决方案中，他们打算在Linux Security Module (LSM)框架中挂接一个模块；这个模块可以配置某特定应用是否具有访问实时调度器的权限。他们将实现后的模块发布到linux-kernel邮件列表中，瞬即就遇到了问题。

对于这些音频开发者来说，安全模块(security module)足以可以解决他们目前遇到的问题。但对于更广大的内核开发社区而言，这却是一种对LSM框架(该模块不是用来给那些本就不会具有权限的进程授权的)的误用，同时对系统稳定也是个风险。因此社区开发者们的首选方案是短期内通过rlimit机制访问实时调度，并将减少延迟作为长期工作。

然而，音频社区不愿放弃他们已经实现的方案，他们不愿接受其他选择。由此导致的分歧让这些开发者不再对整个内核开发过程抱有幻想；其中一个开发者回到audio邮件列表并发表了下面这段话：

这里的确有很多优秀的Linux内核开发者，但他们往往是一群大声喊叫的傲慢自大的傻瓜。和这些人沟通用户需求简直就是浪费时间。他们都太过聪明，根本听不进去凡人的建议。

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

现实的情况却不是这样的；与一个特定的模块相比，内核开发者们更加关心系统的稳定性、长期维护以及找到问题的正确解决方案。这个故事的寓意是把重点放在问题上，而不是某个特定的方案，并且在实现方案前与开发社区进行充分的讨论。

因此，当考虑一个内核开发项目时，每个开发者都应该首先得到下面几个问题的答案：

* 要解决的问题到底是什么？
* 这个问题究竟影响了哪些用户？这个方案到底解决了哪些用例？
* 当前在解决这个问题上内核是如何无法达到要求的？

只有这样，开始考虑可能的方案才是有意义的。

3.2、早期讨论

当规划了一个内核开发项目时，在开始实现前保持与社区的充分讨论是十分有意义的。早期沟通可以从许多方面帮你节省时间和省去麻烦：

* 内核很可能以你未曾听说过的方式解决问题。Linux内核规模巨大，有一些特性和能力并非是显而易见的。另外不是所有的内核能力都有完好的文档的，你很容易错过一些事情。笔者就曾经见到过有人提交的一个完整的驱动程序与已有的驱动程序重复了，并且这个新驱动程序的作者之前并不知道这个驱动程序已经有了。那些重新发明已有轮子的代码不仅仅是浪费，而且它也不会被主线内核接受。

* 提出的方案无法被主线接受也许有很多因素，最好在编写代码前先弄清楚此类问题。

* 其他开发者完全有可能已经考虑过这个问题了；也许他们有更好的解决方案，并且可能愿意帮助你实现那个解决方案。

多年的内核开发社区经验清楚地告诫我们：通过闭门造车设计和开发的内核代码无疑例外都会有这样那样的问题，而这些问题只有在代码被发布到社区后才能被发现。有时，这些问题十分严重，需要几个月或几年努力才能达到内核社区的标准。下面是一些例子：

* Devicescape网络协议栈只是针对单处理器系统设计和实现的。它无法被合并到主线版本，除非它适合多处理器系统。对这些代码做锁改造非常困难。结果，这份代码(现在称为mac80211)的合并工作推迟了一年多。

* Reiser4文件系统包含了许多能力，但核心内核开发者认为这些能力本应该在虚拟文件系统层实现。它还包含了一些特性，但如果不将系统暴露给用户导致的死锁，这些特性就无法轻易实现。后续发现的这些问题 — 以及作者拒绝解决其中一些问题 –导致了Reiser4依旧置身于内核主线之外。

* AppArmor安全模块使用了内部虚拟文件系统的数据接口，这种方式被认为是不安全和不可靠的。虽然代码已经明显做过返工，但仍然被排除在主线之外。

在这些例子中，大量痛苦和多余的工作本可以通过早期与其他内核开发者的讨论而被避免。

3.3、你与谁讨论?

当开发者决定将他们的项目公开时，接下来的问题将是：我们从哪里开始？答案是找到正确的邮件列表(s)以及正确的维护者。对于邮件列表，最佳的方法就是在 MAINTAINERS文件中寻找一个相关的地方。如果存在一个合适的子系统邮件列表，在那里发布往往比在linux-kernel上发布要更好；你更有可能碰到具备相关子系统专业知识的开发者以及更能给你提供支持的环境。

找到维护者可能更为困难些。这次，MAINTAINERS文件依旧可以作为寻找的起点，但该文件的更新不总是那么及时，并且不是所有子系统的维护者都会放在那里。实际上，在MAINTAINERS文件中所列的维护者目前可能已经不再扮演维护者那个角色了。因此，当不知道应该联系谁时，一个实用的技巧是使用 git查看(尤其是"git log")谁是当前你所感兴趣的子系统库的积极开发者。看看谁在写补丁，谁在评审那些补丁。这些人将是给新开发项目带来帮助的最佳人选。

如果以上尝试都失败了，咨询Andrew Morton不失为一个有效的查找特定代码维护者的方法。

3.4、什么时候发布?

如果可能的话，在早期阶段发布你的计划是有帮助的。描述一下你的项目解决的问题以及如何进行实现的计划。你能提供的任何信息都可以帮助开发社区在此项目上提供有用的输入。

在此阶段发生的一个令人沮丧的事情不是怀有敌意的反应，而是少有反应或根本没有反应。这个事情的真实情况是(1)内核开发者都很忙；(2)拥有宏大计划但几乎没有代码(或甚至是代码展望)的人有太多了，(3)没有人有义务去评审或评论其他人发表的想法。如果一个请求发表建议的mail没有收到几条建议，千万不要以为没人对你的项目感兴趣。当然，你也不能假定你的想法就没有任何问题。这种情况下最好的做法是继续做下去，并将你做的事情持续通告给社区。

3.5、获得官方认可

如果你的工作是在公司环境下完成的–就像大多数Linux内核开发工作那样–显然你在将你公司的计划或代码发布到公共邮件列表之前应该先从适当的管理者那获得授权。那些没有清楚地在GPL兼容许可证下发布的代码很可能是有问题的；公司的管理和法律人员越快同意发布这个内核开发项目，参与的人员才能更好的脱离。

一些读者此刻可能会想到他们的内核开发工作是打算支持一个尚未正式承认存在的产品。在一个公共邮件列表上透露他们雇主的计划可能不是一个可行的方案。在这种情况下，值得考虑保密是否真的必要；实际上，常常并不是真的需要对开发计划进行保密。

不过，也有一些情况下，公司不能在其开发过程早期透露其开发计划。拥有丰富经验内核开发者的公司可能选择以开环的方式继续进行，前提是假设他们能够避免后续很多严重的集成问题。对于那些没有专们内核开发经验的公司，常见的最佳选择是雇佣一个外部开发者，让其在不公开协议的约束下去评审开发计划。Linux 基金会运营了一个NDA计划，专门设计用于帮助此类情况；更多的信息参见：http://www.linuxfoundation.org/en/NDA_program

在不要求公开项目的情况下，这种评审对于避免后期出现的一些严重问题往往是足够的了。