Linuxeden开源社区LTTng 跟踪工具包今年已有 20 年的历史，除了基本的最终用户和管理员之外，它已被不同的超大规模企业和其他知名组织（如 IBM、Sony 和 Siemens）广泛采用，以进行系统跟踪/调试。虽然在过去二十年中取得了许多成功，但内核模块仍然在内核树之外。即使有大约四次不同的上游尝试将 LTTng 代码导入主线内核，它仍然没有发生。第五次尝试今天开始，但看起来仍然是一场艰苦的战斗。
LTTng 的创始人 Mathieu Desnoyers 今天再次提出了将 LTTng 内核跟踪器作为主线内核中自己的子系统进行上游的想法。过去让 LTTng 上游而不是基于树外模块的努力在很大程度上失败了，因为它大约有 75k 行新代码，因此需要审查是一项重大任务。一些人还建议将 LTTng 集成到 Linux Perf 子系统中，或者更好地与现有的 Linux 内核子系统统一。
Desnoyers 提出了这个想法，并衡量了通过这个 RFC LKML 线程将 LTTng 内核模块上游到主线内核的反馈。至于如何完成它，偏好似乎是将所有代码批量上游化，以便轻松成为当前使用的 lttng-modules 的直接替代品，并维护现有的用户空间 ABI。与此同时，Desnoyers 指出，如果试图逐步上游代码，这将是一个巨大的承诺，不一定是资金才能使其可行，如果一切都能成功并被证明是值得的，则存在不确定性。Desnoyers 还提出了先将 LTTng 模块提交到内核暂存区域的可能性，同时所有代码都按照主线标准进行清理。
但 Linus Torvalds 已经 对批量上游 LTTng 的前景做出了回应，并且并不完全乐观：
“老实说，我看不出有什么意义。
当前牵引基础设施被合并的原因是人们愿意逐步进行。
我希望不同的环形缓冲区等最终会有某种合并。最初，人们把这当作一个充满希望的最终目标来讨论，但几十年后，它从未发生过。
老实说，我对只有两种不同的跟踪模型不感兴趣。
如果人们需要两个 tracing 模型，那么另一个将来自 tree。就这么简单。
因为如果人们在过去几十年里无法就通用模型达成一致，我真的认为在上游内核中无限期地并排维护两个模型是没有意义的。
所以就我而言，这次讨论不是讨论。要么有一种方法可以与 SHARED 基础设施逐步合并，要么没有。
没有“两个不同且不相交的跟踪缓冲区”。
没有 “两个不同且不相交的跟踪接口”。
很明显——根据历史——统一永远不会发生。
Torvalds 在提出这个想法后进一步评论说，一旦 LTTng 代码在树中，在内核中合并跟踪基础设施会更容易：
“我不会赌。
如果人们在过去二十年里没有统一它，我不会接受“嘿，合并它，因为*那样*它就会被统一”的论点。
因为老实说，这听起来像一个彻头彻尾的童话故事：“公主走过来亲吻了蟾蜍，他变成了一个美丽的 [王子]，他们从此过上了幸福的生活”。
所以没有。我不相信童话故事。当我们有二十年的 “那没有发生 ”的时候，就不会了。
如果人们可以统一它并逐步合并它，那是一回事。
在那之前，你只是在编造东西。
换句话说，“给我看代码”。
因此，尽管 LTTng 已经存在了 20 年，并且得到了许多用户/公司的采用，但鉴于 Linus Torvalds 的最初评论，至少在短期内，其内核模块到达主线内核的可能性似乎仍然非常渺茫。
那些想要了解有关当前 LTTng 功能集的更多信息的人可以通过 LTTng.org 进行。
转自 New Effort To Upstream LTTng In The Linux Kernel Draws Criticism From Torvalds – Phoronix