如何向Linux内核提交潜在的补丁？

Question

我们有一些软件依赖于另一个（非常常用的）应用程序的某些行为，但该应用程序现在已更改，导致我们当前的实现可行但不够优化。

我们认为此更改可能会影响其他许多应用程序，尤其是在性能监控领域，并且我们已经找到了一种解决方案，我们相信这将改善一系列其他潜在问题。

不幸的是，所提出的解决方案是内核更改（相对简单但如果出错影响很大），而我们没有提交内核补丁进行审核的经验。

在SO上是否有人提交过补丁（虽然我会感激所有答案，但我怀疑最好的答案将来自那些经历过该过程的人，即使他们失败了）。您是否已经被接受了（Alan Cox等人是否会关注SO的机会是什么）？

正确的流程是什么？我没有打算给Linus发送电子邮件，因为我知道他有一批保护者，你应该通过他们才能让他看到。我该如何找出谁负责特定部分的内核。

也许我过于乐观地认为内核世界从未听说过的人可以做出贡献，但我很想了解一下。

编辑更多细节：

实际上这个改变不是为了解决一个性能bug，而是在进程终止时写入的过程帐户条目（当前）做出的一个改进（在我看来）。

WebSphere应用程序服务器（啊，IBM，祝福他们的小心灵）已经更改了其行为； JVM通常会定期退出，以便其条目被写入，并且我们可以将其用于计费。现在它让JVM长时间运行数月，这意味着数据无法及时获得，除非我们定期强制关闭WAS。不管怎样，我相信对于其他长时间运行的进程来说，这可能是一个有用的功能。

目前，当进程退出时会写入类型3的进程计费记录。我们正在研究一种机制，可以在进程仍处于活动状态时定期写入类型N的记录，提供自上次写入（或进程启动，如果这是第一次写入）以来的数据。收费或性能监控应用程序可以选择使用类型3记录（完全不变）或过渡类型N记录。我们目前的解决方法是监视/proc/PID/stat中特定进程的情况，但这是一个可怕的巧合，因为它与真正的进程计费集成得不好。

这种写入不需要频繁进行（我们满意每24小时进行一次），但可能会对性能产生影响，因为当前仅在进程退出()时执行的工作将偶尔在进程上下文切换时执行。Linus等人可能不喜欢这个想法，因为这可能是代码的高影响区域（即使检查距离上次写入已经过去了24小时，也可能对他们来说太慢了）。

尽管如此，感谢迄今为止所有的答案，我会看看自己能否解决问题。请给我几天时间，我会接受最佳答案。

- Pax

---

我可以告诉你什么是肯定不对的：给Linus发送邮件。 - eckes

Answer 1

在开始之前，请集中精力处理性能问题的报告，并确保正确（使用可重复的基准测试），这样至少可以让人们关注这个问题。在测试后提交补丁，但要注意您的优秀补丁可能采用错误的方法，并且其他人可能会写得更好。或者，它可能很棒，但需要修正才能被接受，即使是超级专家也有这种情况。不要想着私下向某人发送电子邮件，而应该参考LKML或适当的子系统ML。

我建议您在联系内核开发人员之前先阅读所有其他答案和相关资料，并阅读SubmitingPatches的参考书目。如果做错了，他们可能会很苛刻。Kernelnewbies IRC聊天室是一个不错的起点，因为他们肯定会欢迎您，即使有时环境可能太新手友好了（不确定，我没有太多经验）。

“我可能过于乐观地认为，内核界从未听说过的人也能做出贡献，但我很想发现。”这并不过于乐观；至少就本身而言不是。抽象出您（因为我不知道您的技能），更不可能的是您的补丁将被接受而没有修改，或者它是根据正确的技能编写的。但实际上，如果您的补丁针对较小的社区，则可能会更容易。

来自一些有经验的人（比如我）的建议是，在考虑提交补丁之前，描述问题以及为什么会影响其他应用程序。像“这可以改善我们的性能”这样的考虑，特别是如果您模糊地限定为供应商，将不会吸引内核开发人员。

特别是，省略以下陈述：

"使我们当前的实现可行，但不太理想"

因为这会立即引起大多数读者的“修复您的代码”的建议。如果一个现有应用程序（非由您编写）的性能受到影响，那就不同了。例如，当make中的代码出现问题时，Linus迅速注意到内核性能的修复，即使他为自己编写的代码感到自豪，并且他不需要进行确切的修复。也就是说，你需要一个每个人都关心的应用程序，或者一个没有缺点的解决方案。 因此，像以下内容一样是好的:

来自其他（非常常用的）应用程序的行为

只要你使用该应用程序不被认为是不合理的。

最后，如果你提到源代码，他们可能会要求查看感兴趣的部分——想一想你的代码是否存在许可问题，如果存在，则先解决这些问题，以便快速回答。

顺便说一下，这是我在那里经历的一部分： https://www.ohloh.net/accounts/Blaisorblade 如果您希望，可以直接联系我以提供邮件建议，并将我加入讨论的抄送名单。虽然我很忙，但我可能会找到更多时间 :-）。

- Blaisorblade

Answer 2

好的，您可以尝试阅读位于Linux内核源代码中的 Documentation/SubmittingPatches。

- Chris Young

---

这似乎还好，但是没有明显的领域入口，这意味着我猜我得去麻烦Linus本人了 :-). - paxdiablo

不，你应该发送电子邮件到Linux内核邮件列表，参见第5节第2段。 - Chris Young

我已经提交了一个内核驱动程序，并通过LKML邮件列表获得了接受。这可能是最好的方法。 - Hasturkun

啊，我找不到第5节（只有3节），但我明白你的意思是第1节，第5部分。非常感谢。我会尝试一下。 - paxdiablo

是的，抱歉。第1节，第5个子节，第2段。 :) - Chris Young

Answer 3

在一个大型项目中，将补丁合并到主代码树的最佳方式是联系负责特定代码段的维护人员。因此，请查看Linux MAINTAINERS文件，以查看您更改的代码的维护者是谁，并在Linux内核SCM存储库中查找最近处理该代码的开发人员。为了增加补丁被接受的机会：

• 确保您的补丁易于理解，并遵循现有的代码和文档标准，
• 清楚地解释您的补丁实现了什么功能，
• 以适当的格式提交您的更改（对于Linux，请使用diff -up命令生成输出），
• 确保补丁可以在最新的软件版本（Linux内核）上干净地应用（并且有效），
• 包括演示您正在解决的问题及其补丁如何解决该问题的测试案例，以及
• 不要在您的代码中包含无关的更改（如格式更改）。

修复已知错误的小型补丁比引入边缘或可疑效用的新功能的大型代码更容易被合并到项目中。在某些情况下，值得先通过项目的问题跟踪数据库提交错误报告，然后再提交解决特定问题的补丁。为了避免失望，如果您想进行大规模更改，最好在编写代码之前与维护人员讨论更改及其拟议的实现方式。

- Diomidis Spinellis

Answer 4

阅读文档/提交补丁，找到适当的维护者，并最重要的是，发现所有讨论真正发生的地方。可能不在内核邮件列表本身上，而是在某些子系统 ML 上。

然后订阅此 ML，并将您的补丁作为 RFC 提交。

我不知道您的补丁是否具有侵入性，但请尝试将其拆分为一系列逻辑更改的队列，每个更改都有自己的说明。

- shodanex

Answer 5

我自己还没有尝试过提交任何内核补丁，而且在这个领域文档不足。

但是这个页面看起来可以指导你朝着正确的方向前进。

- OIS

---

我特别喜欢WhatNotToDo部分（“你们都是白痴！”）。这样应该能避免任何初始问题。 - paxdiablo

而且还有“GettingFlamed”，这可能是大多数新提交者经历的。 :) - OIS

Answer 6

在编辑方面，答案可能作为一个典型案例很有趣。 我想你的要求完全合理，但是你说即使是上下文切换测试也太贵了。但既然内核有定时器实现，我认为它可以用来避免这种情况。因此，建议发起增强请求是最安全的选择。 我很惊讶，建议发送错误报告而不是修补程序如此契合。 如果您想提交修补程序，还可以自己修改修补程序以使用计时器，但仍需准备好讨论 :-) 您甚至可以添加“我们有一个本地修复方案，但它会在快速路径上添加一些上下文切换测试，这就是为什么附加了补丁供参考但不应应用”的说明。如果已知自己的代码存在问题，则拒绝自己的代码将避免对修补程序的严厉审查。

另一种选择是运行一些基准测试并证明没有影响，但如果定时器可行，那么该代码也将被拒绝，或者尝试使用定时器解决方案（可能存在更好的解决方案）。 找到他们用于内核调度程序的基准测试；查看有关CFS Ingo（或Kolivas？）修补程序的“最近”线程并参考他们的基准测试。

关于支持，内核开发人员不会单独关心“Websphere应用服务器”，如果它做出不合理的事情，即使是IBM资助的也不会关心。但是根据我有限的了解，定期关闭JVM没有意义，似乎只是掩盖某些内存泄漏/不稳定性的方法，因此必须支持当前行为。

- Blaisorblade

---

我绝不会向开发人员建议这是一个错误，显然这是一种增强功能 - 我接受了你之前的答案，因为其中包含其他信息。总之，它现在已经发布在LKML上供全世界查看和讨论。有一条消息回来，似乎DB2也类似于WAS，希望不仅仅是IBM会受益。 - paxdiablo

你很抱歉，我忽略了这个非常重要的细节。 - Blaisorblade