我们有一些软件依赖于另一个（非常常用）应用程序的某些行为，这些行为现在已经改变，使我们当前的实现可行，但不是最佳。
我们认为这一变化可能会影响其他一些应用，特别是在性能监控领域，我们已经找到了一个解决方案，我们认为这将解决其他一些潜在的问题。
不幸的是，所说的解决方案是内核更改（相对简单，但如果我们填写它会产生很大影响），我们没有提交内核补丁进行审核的经验。
有没有人在SO上提交了一个补丁（虽然我很欣赏所有的答案，但我怀疑最好的答案会来自那些已经完成整个过程的人，甚至没有成功）？你有没有接受过（Alan Cox等人对SO有什么机会）？
要遵循的正确流程是什么？我无意向Linus发送一封电子邮件，因为我知道他有一群保护者，你应该在他到达之前通过。我如何找出谁负责内核的特定部分。
我可能会过于乐观地认为某个内核世界从未听说过可以做出贡献，但我有兴趣了解一下。
编辑更多细节：
更改实际上并不是针对性能错误，而是对进程终止时编写的进程记帐条目（当前）的改进（在我看来）。
Websphere App Server（啊，IBM，祝福他们的小心灵）改变了它的作用; JVM过去经常退出以便他们的条目被写入，我们可以将其用于退款。现在它让JVM闲置数月，这意味着数据无法及时获得，除非我们定期强制关闭WAS。不知怎的，我不认为IBM软件集团会为我们修复他们的软件:-)。在任何情况下，我相信它对于其他长期过程可能是一个有用的特性。
当进程退出时，会写入当前的类型3进程记帐记录，我们正在查看的是一种在进程仍处于活动状态时定期写入类型N记录的机制，给出自上次写入以来的数字（或进程启动时如果这是第一次）。退款或性能监控应用程序可以选择使用类型3记录（完全不变）或临时类型N记录。我们目前的解决方法是监控特定流程的/ proc / PID / stat，但这是一个可怕的问题，因为它与实际流程会计不能很好地集成。
不一定经常（我们会对24小时感到满意），但可能会对性能产生影响，因为目前仅在流程退出（）上完成的工作必须偶尔在流程上下文切换时完成。 Linus等人可能不喜欢这个想法，因为它可能是代码的一个影响很大的区域（甚至检查自上一次写入以来是否已经24小时对他们来说太慢了）。
仍然，感谢到目前为止的所有答案，我会看到我如何去。给我几天，我会接受最好的答案。
答案 0 :(得分：14)
其他事情： 专注于性能错误报告，并正确（具有可重复的基准）将至少帮助您让人们打扰这个问题。在测试之后再提交补丁，但要注意你的优秀补丁可能使用错误的方法，并且他们可能会写一个更好的补丁。或者说它可能很棒，但可能需要修复才能被接受，甚至可能发生在优步人身上。并且不要想私下给某人发电子邮件，而是参考LKML或相应的子系统ML。
我建议您在联系内核开发人员之前先阅读所有其他答案和所有适用的材料;并阅读SubmittingPatches的参考书目。 如果你做错了，他们可能会很苛刻。核心新闻IRC聊天是你开始的好地方，因为它们肯定是热情好客，即使有时环境可能太新手了（不确定，我也没有那么多）。
我可能会过于乐观地认为某个内核世界从未听说过可以做出贡献，但我有兴趣了解一下。
这并不过分乐观;至少不是这样。从你的摘要（因为我不知道你的技能），更不可能的是你的补丁将被接受而不做任何修改，或者它是根据正确的技能编写的。但实际上，如果您的补丁适用于较小的社区，则可能会更容易。
从有经验的人（即我），在考虑提交补丁之前，描述问题及其影响其他应用程序的原因。诸如“这可以提高我们的性能”等考虑因素，特别是如果您（作为供应商）有资格获得资格，则不会对内核开发人员有吸引力。
特别是，省略这样的陈述：
使我们当前的实现可行，但不是最佳。
因为这会为大多数读者立即购买“修改代码”的建议。
如果现有应用程序（不是您编写的）的性能受到影响，则会有所不同。例如，一旦Linus立即注意修复内核性能以搞砸代码，因为该代码是make的一部分，即使他为他编写的代码以及他不需要做的事情感到自豪确切的修复。即，您需要一个每个人都关心的应用程序，或者一个没有缺点的解决方案。 所以，像：
来自另一个（非常常用的）应用程序的行为
是好的，只要您认为该应用程序的使用不合理。
最后，如果您参考源代码，他们可能会要求查看感兴趣的部分 - 如果存在代码，请考虑许可问题，如果您想快速回答，请事先解决其中任何问题。< / p> 不过，这是我在那里的部分经历： https://www.ohloh.net/accounts/Blaisorblade
如果您愿意，可以与我联系，直接向您提供建议的邮件，并在讨论中与我联系。我很忙，但我可能会找到更多的时间： - ）。
答案 1 :(得分：13)
好吧，你可以尝试在linux内核源代码树中阅读Documentation/SubmittingPatches。
答案 2 :(得分：4)
在大型项目中，将修补程序放入主树的最佳方法是联系维护特定代码段的人员。因此，查看Linux MAINTAINERS file以查看谁是您已更改的代码的正式维护者，并在Linux kernel SCM repository找到最近处理该代码的开发人员。为了增加补丁被接受的机会：
对于已知错误的小修复更有可能被纳入项目，而不是引入边缘或可疑实用新功能的大型代码更改。在某些情况下，首先通过项目的问题跟踪数据库提交错误报告是值得的，然后提交一个解决特定问题的补丁。为避免失望，如果您正在考虑进行大的更改，最好在编写代码之前与维护者讨论更改和建议的实现。
答案 3 :(得分：2)
阅读Documentation / SubmittingPatches，找到合适的MAINTAINER，最重要的是，发现所有讨论真正正在发生的地方。 它可能不在内核邮件列表本身，但可能在某些子系统ML上。
然后订阅此ML，并将您的补丁作为RFC提交。
我不知道您的补丁是否具有侵略性，但是尝试将其拆分为逻辑更改队列，每个补丁都有自己的解释。
答案 4 :(得分：1)
我没有尝试过自己提交任何内核补丁，以及此区域的docs are lacking。
但是this page看起来可以指向正确的方向。
答案 5 :(得分：1)
在编辑中，答案可能是一个有趣的例子。 我猜你的要求是完全合理的，但你是对的，即使对上下文切换的测试也可能太昂贵。但由于内核有一个定时器实现，我不明白为什么它不能用来避免它。因此，确实提出增强请求是最安全的选择。 我很惊讶，建议发送错误报告而不是补丁是非常合适的。 您也可以自己修改补丁以自行使用定时器，如果您想提交定时器，但仍可以进行讨论:-) 你甚至可以添加“我们有一个本地修复，但它在上下文切换快速路径上添加了一些测试，这就是附加补丁以供参考但不应该应用的原因”。关闭自己的代码，如果知道它是坏的，将避免对补丁进行严格的审查。
替代方案是运行一些基准并证明没有影响，但是如果定时器是可行的，那么代码将被拒绝，或者自己尝试定时器解决方案（可能存在更好的东西）。 找到他们用于内核调度程序的基准测试;看看有关CFS Ingo（或Kolivas'？）补丁的“近期”线索并采取他们的基准。
关于支持，内核开发人员本身并不关心“Websphere App Server”，如果它做不合理的事情，甚至不是IBM资助的事情。但由于我对情况的了解有限，定期关闭JVM没有意义，它似乎只是一种记录内存泄漏/不稳定的方法，因此必须支持当前的行为。