17

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

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

不幸的是，上述解决方案是内核更改（相对简单但如果我们把它塞进去会产生很大影响），我们没有提交内核补丁以供审查的经验。

SO上有没有人真的提交了一个补丁（虽然我很感激所有的答案，但我怀疑最好的答案来自那些已经通过这个过程的人，即使是不成功的）？您是否已接受它（Alan Cox 等人在 SO 上徘徊的机会有多大）？

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

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

编辑更多细节：

更改实际上并不是针对性能错误，而是（在我看来）对进程终止时写入的进程会计条目（当前）的改进。

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

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

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

不过，感谢到目前为止所有的答案，我会看看我怎么走。给我几天，我会接受最好的答案。

4

6 回答 6

14

最重要的是：专注于性能错误报告，并正确处理（使用可重复的基准测试）至少可以帮助您让人们为问题烦恼。同样在测试后提交补丁，但要注意你的好补丁可能使用错误的方法，并且他们可能会写出更好的补丁。或者只是它可能很棒，但可能需要修复才能被接受，这甚至发生在超级家伙身上。并且不要想私下给某人发电子邮件，而是参考 LKML 或适当的子系统 ML。

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

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

并不过分乐观。至少本身不是。从你那里抽象出来（因为我不知道你的技能），更不可能的是你的补丁会在没有修改的情况下被接受，或者它是根据正确的技能编写的。但实际上，如果您的补丁针对的是较小的社区，则可能会容易得多。

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

特别是，省略这样的陈述：

使我们当前的实现可行，但不是最佳的。

因为这会立即得到大多数读者的“修复代码”建议。

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

来自另一个（非常常用的）应用程序的行为

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

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

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

如果你愿意，你可以联系我直接帮助你提供建议的邮件，并在讨论中抄送我。我很忙，但我可能会找到更多时间:-)。

于 2009-01-12T08:43:33.820 回答
13

好吧，您可以尝试阅读linux 内核源代码树中的Documentation/SubmittingPatches。

于 2009-01-12T07:44:46.293 回答
4

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

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

与引入边缘或可疑实用程序的新功能的大型代码更改相比，对已知错误的小修复更有可能被合并到项目中。在某些情况下，首先通过项目的问题跟踪数据库提交错误报告是值得的，然后提交解决特定问题的补丁。为避免失望，如果您正在考虑进行重大更改，最好在编写代码之前与维护人员讨论更改和您提议的实现。

于 2009-01-12T07:54:57.163 回答
2

阅读 Documentation/SubmittingPatches，找到合适的 MAINTAINER，最重要的是，发现所有讨论真正发生在哪里。它可能不在内核邮件列表本身，但可能在某些子系统 ML 上。

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

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

于 2009-01-12T08:41:33.887 回答
1

我没有尝试自己提交任何内核补丁，而且这方面的文档也很缺乏。

但是此页面看起来可以为您指明正确的方向。

于 2009-01-12T07:41:48.017 回答
1

在 EDIT 中，作为示例，答案可能很有趣。我想你的要求是完全合理的，但你是对的，即使是对上下文切换的测试也可能过于昂贵。但是由于内核有一个计时器实现，我不明白为什么不能用它来避免这种情况。因此，确实，提出增强请求是最安全的选择。我很惊讶建议发送错误报告而不是补丁非常合适。如果您想提交它，您也可以自己修改补丁以自己使用计时器，但仍准备好进行讨论:-) 您甚至可以添加“我们有一个本地修复，但它在上下文切换快速路径上添加了一些测试，这就是为什么附上补丁以供参考但不应应用的原因”。拒绝你自己的代码，如果它被认为是坏的，

另一种方法是运行一些基准测试并证明没有影响，但如果计时器可行，那么代码无论如何都会被拒绝，或者自己尝试计时器解决方案（可能存在更好的解决方案）。找到他们用于内核调度程序的基准；查看有关 CFS Ingo（或 Kolivas'？）补丁的“最近”线程并获取他们的基准。

关于支持，内核开发人员不会关心“Websphere App Server”本身，如果它做了不合理的事情，即使是 IBM 资助的事情。但是由于我对这种情况的了解有限，定期关闭 JVM 是没有意义的，这似乎只是掩盖一些内存泄漏/不稳定的一种方式，因此必须支持当前的行为。

于 2009-01-13T18:33:47.280 回答