• https://www.kernel.org/doc/html/v6.6/process/3.Early-stage.html

3. 早期规划

在考虑 Linux 内核开发项目时，很容易就跃跃欲试，开始编码。然而，与任何重要项目一样，成功的基础工作最好是在编写第一行代码之前完成的。在早期规划和沟通上花费一些时间，可以在以后节省更多的时间。

3.1. 确定问题

像任何工程项目一样，成功的内核增强从清晰描述待解决问题开始。在某些情况下，这一步很容易：例如，当需要为特定硬件编写驱动程序时。然而，在其他情况下，很容易将真正的问题与提出的解决方案混淆，这可能会导致困难。

举个例子：一些年前，与 Linux 音频相关的开发人员寻求一种方法，使应用程序在系统中由于过高的延迟而导致的中断或其他问题。他们提出的解决方案是一个旨在连接到 Linux 安全模块（LSM）框架的内核模块；该模块可以配置为使特定应用程序能够访问实时调度程序。该模块被实现并发送到 linux-kernel 邮件列表，但立即遇到了问题。

对于音频开发人员来说，这个安全模块足以解决他们的直接问题。然而，对于更广泛的内核社区来说，这被视为对 LSM 框架的误用（该框架并非用于授予进程它们本来不具备的特权），并对系统稳定性构成风险。他们更倾向于通过 rlimit 机制实现短期内的实时调度访问，并在长期内进行延迟降低工作。

然而，音频社区无法看到他们实施的特定解决方案之外的其他选择；他们不愿接受其他替代方案。由此产生的分歧使得这些开发人员对整个内核开发过程感到幻灭；其中一人回到音频列表并发表了这样的言论：

"有很多优秀的 Linux 内核开发人员，但他们往往被一大群傲慢的愚蠢人所掩盖。试图向这些人沟通用户需求是浪费时间。他们太“聪明”了，不愿听取下等的普通人的意见。"

（来源：lwn.net）

事实情况是不同的；内核开发人员更关心系统稳定性、长期维护以及找到问题的正确解决方案，而不是特定模块。这个故事的寓意是要专注于问题本身，而不是特定的解决方案，并在创建大量代码之前与开发社区讨论。

因此，在考虑内核开发项目时，应该先回答一系列问题：

• 到底是什么问题需要解决？
• 哪些用户受到这个问题的影响？解决方案应该涵盖哪些使用案例？
• 内核目前在解决这个问题上存在哪些不足？

只有在回答了这些问题之后，才有意义去考虑可能的解决方案。

3.2. 早期讨论

在规划内核开发项目时，与社区进行讨论是非常明智的。早期沟通可以在许多方面节省时间和麻烦：

• 可能内核已经以你没有意识到的方式解决了问题。Linux 内核庞大，具有许多功能和能力，这些并不是显而易见的。并非所有内核功能都有令人满意的文档，很容易忽略一些东西。我曾看到过完全重复了现有驱动程序的完整驱动程序的发布，而新作者并不知道已存在的驱动程序。重新发明轮子不仅是浪费，而且也不会被合并到主线内核中。

• 提出的解决方案可能有一些不适合主线合并的元素。最好在编写代码之前发现这类问题。

• 完全有可能其他开发人员已经考虑过这个问题；他们可能对更好的解决方案有想法，并且可能愿意在创建解决方案时提供帮助。

多年来与内核开发社区的经验教会了一个明显的教训：在闭门设计和开发的内核代码往往只有在代码发布到社区后才会显露出问题。有时这些问题很严重，需要数月甚至数年的努力才能使代码达到内核社区的标准。一些例子包括：

• Devicescape 网络堆栈最初是为单处理器系统设计和实现的。直到它适用于多处理器系统之前，它才能合并到主线内核。在代码中添加锁等内容是一项困难的任务；因此，这段代码（现在称为 mac80211）的合并被推迟了一年多。

• Reiser4 文件系统包含了一些核心内核开发人员认为应该在虚拟文件系统层面实现的功能。它还包括一些很难在不暴露系统给用户引起死锁的情况下实现的功能。这些问题的晚期显露以及拒绝解决其中一些问题，导致 Reiser4 无法进入主线内核。

• AppArmor 安全模块在使用内部虚拟文件系统数据结构的方式被认为是不安全和不可靠的。这个担忧（以及其他担忧）使 AppArmor 多年无法进入主线。

在这些情况下，通过与内核开发人员进行早期讨论，可以避免很多痛苦和额外工作。

3.3. 与谁交流？

当开发人员决定公开他们的计划时，下一个问题将是：我们从哪里开始？答案是找到正确的邮件列表和正确的维护者。对于邮件列表，最好的方法是在 MAINTAINERS 文件中查找适当的发布位置。如果有适当的子系统列表，那么在那里发布通常比在 linux-kernel 上发布更好；你更有可能联系到具有相关子系统专业知识的开发人员，并且环境可能更加支持。

找到维护者可能有点困难。同样，MAINTAINERS 文件是开始的地方。然而，该文件通常并不总是最新的，并且并非所有子系统都在其中有代表。在 MAINTAINERS 文件中列出的人员实际上可能并非当前担任该角色的人员。因此，当不确定要联系谁时，一个有用的技巧是使用 git（特别是 "git log"）来查看谁当前在感兴趣的子系统中活跃。看看谁在编写补丁，以及谁（如果有的话）在这些补丁上附加 Signed-off-by 行。这些人将是最适合帮助新开发项目的人员。

找到正确的维护者的任务有时候是相当具有挑战性的，以至于内核开发人员已经添加了一个脚本来简化这个过程：

.../scripts/get_maintainer.pl

当使用 "-f" 选项时，该脚本将返回给定文件或目录的当前维护者。如果在命令行上传递了一个补丁，它将列出应该收到该补丁副本的维护者。这是获取应该抄送你的补丁的人员列表的首选方式（与 "-f" 选项不同）。有许多选项来调节 get_maintainer.pl 将如何搜索维护者；请小心使用更激进的选项，因为你可能最终会包括对你修改的代码没有真正兴趣的开发人员。

如果其他方法都失败了，与 Andrew Morton 谈话可能是追踪特定代码维护者的有效方式。

3.4. 何时发布？

如果可能的话，在早期阶段发布你的计划只会有益无害。描述正在解决的问题以及已经制定的实施计划。你提供的任何信息都可以帮助开发社区对项目提供有用的意见。

在这个阶段可能会发生的令人沮丧的事情不是敌对的反应，而是几乎没有反应。事实上，问题是（1）内核开发人员往往很忙，（2）有很多人有宏伟计划，但却没有代码（甚至没有代码的前景）来支持它们，（3）没有人有义务审查或评论他人发布的想法。此外，高层设计通常隐藏了只有在有人实际尝试实施这些设计时才会显露出的问题；因此，内核开发人员更愿意看到代码。

如果一个请求评论的发布没有得到太多评论，不要假设这意味着项目没有兴趣。不幸的是，你也不能假设你的想法没有问题。在这种情况下最好的做法是继续前进，并在进行过程中让社区了解你的进展。

3.5. 获得官方支持

如果你的工作是在公司环境中进行的 - 大多数 Linux 内核工作都是如此 - 那么在将公司的计划或代码发布到公共邮件列表之前，你显然必须得到适当授权的管理人员的许可。发布未经 GPL 兼容许可证批准的代码可能会特别棘手；公司管理层和法律人员越早就内核开发项目的发布达成一致意见，所有相关人员就会越好。

一些读者可能会认为，他们的内核工作旨在支持尚未正式确认存在的产品。在公共邮件列表上透露雇主的计划可能并不是一个可行的选择。在这种情况下，值得考虑的是保密是否真的是必要的；通常情况下并没有真正需要将开发计划保密。

也就是说，也有一些情况下，公司确实无法在开发过程的早期披露其计划。有经验的内核开发人员可能选择在假设他们将能够避免后期的严重集成问题的情况下以开放环路方式进行。对于没有这种内部专业知识的公司来说，最好的选择通常是雇佣外部开发人员以在保密协议下审查计划。Linux 基金会运营着一个旨在帮助处理这种情况的 NDA 计划；更多信息可以在以下链接找到：

https://www.linuxfoundation.org/nda/

这种审查通常足以避免后期出现严重问题，而不需要公开项目。