3. 早期规划¶
在考虑 Linux 内核开发项目时，人们可能会很想直接开始编码。但是，与任何重大项目一样，成功的基础最好在编写第一行代码之前就打好。在早期规划和沟通上花费一些时间可以节省以后更多的时间。
3.1. 明确问题¶
像任何工程项目一样，成功的内核增强始于对要解决的问题的清晰描述。在某些情况下，这一步很容易：例如，当需要为特定硬件编写驱动程序时。但在其他情况下，人们很容易将真正的问题与提出的解决方案混淆，这可能会导致困难。
考虑一个例子：几年前，使用 Linux 音频的开发人员寻求一种方法来运行应用程序，而不会因系统中的过度延迟而导致丢帧或其他伪影。他们得出的解决方案是一个旨在挂钩到 Linux 安全模块 (LSM) 框架的内核模块；可以配置此模块，以允许特定应用程序访问实时调度程序。这个模块被实现并发送到 linux-kernel 邮件列表，但立即遇到了问题。
对于音频开发人员来说，这个安全模块足以解决他们眼下的问题。但是，在更广泛的内核社区看来，这被视为对 LSM 框架的滥用（该框架并非旨在将权限授予本来不具备权限的进程），并且是对系统稳定性的威胁。他们首选的解决方案是短期内通过 rlimit 机制进行实时调度访问，以及长期进行延迟降低工作。
然而，音频社区却无法超越他们已经实现的特定解决方案；他们不愿意接受替代方案。由此产生的分歧使这些开发人员对整个内核开发流程感到失望；其中一位回到音频列表并发布了以下内容
有很多非常优秀的 Linux 内核开发人员，但他们往往被一大群傲慢的傻瓜淹没。试图向这些人传达用户需求是在浪费时间。他们太“聪明”了，听不进凡人的意见。
(https://lwn.net/Articles/131776/)。
实际情况并非如此；内核开发人员更关心的是系统稳定性、长期维护以及找到解决问题的正确方法，而不是特定的模块。这个故事的寓意是专注于问题——而不是特定的解决方案——并在投入创建代码之前与开发社区讨论。
因此，在考虑内核开发项目时，应该获得以下问题的答案
究竟是什么问题需要解决？
哪些用户会受到此问题的影响？解决方案应解决哪些用例？
内核现在在解决该问题方面有何不足？
只有这样，才开始考虑可能的解决方案才有意义。
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（保密协议）计划，旨在帮助解决这种情况；更多信息可以在这里找到：
这种审查通常足以避免以后出现严重问题，而无需公开披露项目。