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

Question

我们有一些软件依赖于另一个(非常常用)应用程序的某些行为，这些应用程序现在已经改变，使我们当前的实现可行，但不是最佳的。

我们相信这一变化可能会影响许多其他应用程序，特别是在性能监控领域，我们已经找到了一个解决方案，我们相信该解决方案将改善许多其他潜在问题。

不幸的是，所述解决方案是内核更改(相对简单但如果我们将其塞满会产生很大影响)并且我们没有提交内核补丁以供审核的经验。

SO 上有没有人实际提交了补丁(虽然我很感激所有答案，但我怀疑最好的答案将来自那些已经完成该过程的人，即使没有成功)？您是否接受了它(Alan Cox 等人坚持 SO 的可能性有多大)？

要遵循的正确流程是什么？我无意向 Linus 发送电子邮件，因为我知道他有一群保护者，你应该在它到达他之前通过这些保护者。我如何找出谁负责内核的特定部分。

可能是我过于乐观地认为内核世界从未听说过的人可以做出贡献，但我很想知道。

---

编辑更多细节:

更改实际上不是性能错误，而是(在我看来)对进程终止时写入的进程记帐条目(当前)的改进。

Websphere App Server(啊，IBM，保佑他们的小心脏)改变了它的功能； JVM 过去常常定期退出，以便写入它们的条目，我们可以将其用于计费。现在它让 JVM 闲置了几个月，这意味着除非我们定期强制关闭 WAS，否则数据无法及时获得。不知何故，我认为 IBM 的软件组不会为我们修复他们的软件 :-)。无论如何，我相信对于其他长期存在的进程来说，这可能是一个有用的特性。

目前 type-3 进程记帐记录是在进程退出时写入的，我们正在研究的是一种机制，可以在进程仍处于事件状态时定期写入 type-N 记录，给出自上次写入以来的数字(如果进程启动)这是第一次)。计费或性能监控应用程序可以选择使用类型 3 记录(完全不变)或临时类型 N 记录。我们当前的解决方法是监视特定进程的/proc/PID/stat，但这是一个可怕的问题，因为它不能很好地与实际进程记帐集成。

它不需要经常(我们对 24 小时感到满意)但可能会对性能产生影响，因为当前仅在进程 exit() 上完成的工作必须偶尔在进程上下文切换时完成。 Linus 等人可能不喜欢这个想法，因为它可能是代码的一个高影响区域(即使检查自上次写入以来是否已经过去 24 小时对他们来说也太慢了)。

不过，感谢您到目前为止的所有回答，我会看看如何进行。给我几天时间，我会接受最佳答案。

Answer 1

首先:专注于性能错误报告，并使其正确(使用可重复的基准测试)至少会帮助您让人们为这个问题烦恼。还要在测试后提交补丁，但要注意你的补丁可能使用了错误的方法，他们可能会写出更好的方法。或者只是它可能很棒，但可能需要修复才能被接受，甚至发生在 uber-guys 身上。不要想私下给某人发电子邮件，而是引用 LKML 或适当的子系统 ML。

我建议您在联系内核开发人员之前通读所有其他答案和所有适用 Material ；并阅读 SubmittingPatches 的引用书目。如果你做错了，他们可能会很严厉。 kernelnewbies IRC 聊天是您开始的好地方，因为他们肯定很热情，即使有时环境可能太像新手(不确定，我没去过那里)。

It may be that I'm being overly optimistic in thinking someone the kernel world's never heard of can contribute, but I'd be interested to find out.

这并不过分乐观；至少本身不是。从您那里抽象出来(因为我不知道您的技能)，更不可能的是您的补丁将不经修改就被接受，或者它是根据正确的技能编写的。但实际上，如果您的补丁是针对较小的社区，可能会容易得多。

有经验的人(比如我)，在考虑补丁提交之前，描述问题以及它影响其他应用程序的原因。诸如“这提高了我们的性能”之类的考虑因素，尤其是如果您(模糊地)有资格作为供应商，对内核开发人员没有吸引力。

尤其要省略这样的语句:

rendering our current implementation workable, but less than optimal.

因为大多数读者会立即向您推荐“修复代码”。

如果现有应用程序(不是您编写的)的性能受到影响，那就不同了。例如，一旦 Linus 立即注意修复内核性能以修复搞砸的代码，因为该代码是 make 的一部分，即使他为自己编写的代码以及他不需要做的事实感到自豪那个确切的修复。也就是说，您需要一个每个人都关心的应用程序，或者一个没有缺点的解决方案。所以，像这样的东西:

behavior from an another (very commonly used) application

很好，只要您对该应用程序的使用不被视为不合理。

最后，如果您引用源代码，他们可能会要求查看感兴趣的部分 - 如果您的代码存在许可问题，请考虑解决这些问题，如果您想快速回答这些问题，请提前解决。

顺便说一句，这是我在那里的部分经历: https://www.ohloh.net/accounts/Blaisorblade

如果需要，您可以联系我直接通过建议的邮件帮助您，并在讨论中抄送我。我很忙，但我可能会找到更多时间 :-)。