linux内核提交系列补丁,如何向Linux内核提交潜在补丁？

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

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

不幸的是，所说的解决方案是一个内核的变化(相对简单，但是如果我们填写它会很有影响)，而且我们没有提交内核补丁以供审核的经验。

有没有人真的提交了一个补丁(虽然我会感谢所有的答案，我怀疑最好的将来自那些已经通过这个过程，甚至没有成功)？你有没有接受(Alan Cox等人在SO上有什么机会)？

正确的过程是什么？我没有意图发给Linus的电子邮件，因为我知道他有一个干部的保护者，你应该在他得到之前经过。我如何知道谁负责内核的特定部分。

可能是因为内核世界从来没有听说过可以贡献的人，我过分乐观，但我有兴趣了解。

编辑更多细节：

这种变化实际上并不是一个性能错误，而是一个改进(在我看来)到流程终止时写入的进程记帐条目(当前)。

Websphere App Server(啊，IBM，祝福他们的小心)改变了它的作用; JVM用于定期退出，以便他们的条目被写入，我们可以使用它来进行退款。现在它让JVM躺在几个月之内，这意味着数据不及时可用，除非我们强制WAS定期关闭。不知怎的，我不认为IBM软件集团将为我们修复他们的软件:-)。无论如何，我相信对于其他长期存在的过程来说，这可能是一个有用的功能。

当进程退出时，目前的类型3进程会计记录是写入的，我们正在查看的是一个机制，在进程仍然活动时定期写入N类记录，从上次写入(或进程启动，如果这是第一次)。退款或绩效监控应用程序可以选择使用3类记录(完全不变)或中间类型N记录。我们目前的解决方法是监控/ proc / PID / stat的具体过程，但这是一个可怕的kludge，因为它不能很好地与真正的流程会计整合。

它不需要经常(我们很高兴24小时)，但可能会产生性能影响，因为目前仅在进程退出()执行的工作将不得不在进程上下文切换时进行。 Linus等人可能不喜欢这个想法，因为它可能是代码的高影响区域(甚至检查是否有24小时，因为最后一次写入可能对他们来说太慢)。

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