LWN: 如何让LTTng能继续正常工作？

关注了就能看到更多这么棒的文章哦～

How to unbreak LTTng

By Jonathan Corbet
April 20, 2020

原文来自：https://lwn.net/Articles/817988/

主译：DeepL

早在2月份，内核社区就讨论过删除几个函数，因为他们可能会被loadable module利用来访问一些符号（函数和数据结构），而这些符号（函数和数据结构）本来是不应该被这些module所使用的。这一改动在5.7合并窗口期间就合入kernel了。这将导致此前依赖这些函数的module出错。由于这些模块大多都是proprietary（专有）的，因此内核社区没什么人对此担心。但有一些内核tree之外的module，使用了GPL兼容的许可证，他们也受到了这个改动的影响，LTTng就是其中之一。修复LTTng可能并不是很简单。

LTTng 属于tracing subsystem领域，要执行tracing任务，它必须能够在内核中许多深入位置加上hook。那么LTTng访问到kernel中被认为不适合导出到module的部分也就不足为奇了。无法访问kallsyms_on_each_symbol()之后，LTTng就无法查找这些地址了，从而导致破坏它的大部分功能无法正常工作了。这对于那些开发 LTTng 或者使用 LTTng 的人来说，肯定不是一个好消息。

LTTng 开发者 Mathieu Desnoyers 对这一变化采取了一些措施。他准备了patch set来导出一些新的符号；有了这些符号，LTTng 就可以做它需要做的事情，而不需要使用更通用的 kallsyms_on_each_symbol() 函数。例如，LTTng需要访问stack_trace_save_user()函数来保存用户空间的堆栈痕迹。还需要能访问task_prio()、disk_name()和get_pfn_blocks_mask()等函数。当然，LTTng也会从 tracepoints 中获取内核信息，随着 tracepoints 取代了之前使用的一些直接访问内部信息的方式，也更加适合这种用法了。此patch set将在tracepoint位置用于传递给BPF程序的参数数量提高到了13个（这样每个tracepoint位置就可以传递出更多的信息），但这个改动最终可能是用不到的。

任何关注过内核社区一段时间的人，都能猜到这个patch set收到了什么样的回应。Christoph Hellwig很直率地说道："Which part of every added export needs an in-tree user did you not get?" 内核社区整体态度都非常强烈反对为内核仓库之外的代码添加任何形式的支持。这种抵触很大程度上是来自于对proprietary kernel modules的厌恶，但这并不仅仅因为这个。

LTTng，作为自由软件，不会像proprietary kernel code那样受大家反感。但是，正如Greg Kroah-Hartman所解释的那样，仍然有理由避免增加对免费的、out-of-tree module的支持。一旦这些module以某种方式得到了支持，它们就会给内核开发者能做的事情增加限制。内核内部接口可以根据需要随时进行更改，由于这些接口的所有调用者都存在于同一个代码库中，所以可以同时更改掉。但是，如果必须支持external module，那么要很难进行这类修改，因为调用这个改动过的接口的代码无法及时修改，从而导致接口不匹配问题。事实上，甚至改完之后都很难知道未来是不是会在某些应用场景下导致问题。

因此，Kroah-Hartman说：

We can't do anything for out-of-tree modules as they suddenly become "higher priority" than in-tree code if you have to not do specific changes or extra work for them. Which is not fair at all to the in-tree code developers at all.

这一切都表明，LTTng的发展前景并不明朗。如果无法访问内核内部信息，它就无法运行。而此刻大家已经明确拒绝了给它这个访问权限。

当然，还有一个选择，这是由Steve Rostedt首先提出的："I guess we should be open to allowing LTTng modules in the kernel as well"。如果LTTng是mainline kernel的一部分，那么就不会再有问题了，它会拥有所需要资源的访问权限。

这不是一个新的想法。人们曾多次尝试将LTTng代码纳入主线内核，但都没有成功。在早期，内核还没有任何tracing功能之前，添加这个功能是很难做到的。现在的内核开发者在他们的工作中非常依赖tracing，他们会强烈抵制任何试图剥夺这一功能的行为，但就在不久前，同样这些开发者还不相信tracing功能是必要的。在那时候，要把任何tracing功能引入内核并不容易。

随着时间的推移，LTTng的一些底层代码已经合入内核了，但LTTng作为一个整体并没有跟着合入。最近，在2011年，Kroah-Hartman将LTTng加入了Staging Tree，作为合并LTTng的第一步。这一举动带来了大量的反对意见，其中一些意见似乎我们都很眼熟。例如，在把task_prio给export出来的时候可能会触发一个非常耗时的线程。最终，LTTng 从staging tree中被移除了——跟之前一样，回到了原点。

因此，LTTng似乎处于一个两难境地：无法独立于kernel来工作，但也无法被合并入kernel。但是，如果LTTng 无法使用的话，会对许多用户造成严重的伤害，这样也不太可能对推动 Linux 或自由软件的发展有好处。所以，也许是时候该对LTTng好一些了。如果真的不能为这个subsystem允许export出来很少的一些符号，也许可以想些办法在mainline kernel中为这么一个广泛使用的tracing subsystem准备一个容身之所，即便它在某种程度上是跟以前一些功能有重复也没关系。

全文完

LWN文章遵循CC BY-SA 4.0许可协议。

欢迎分享、转载及基于现有协议再创作～

长按下面二维码关注，关注LWN深度文章以及开源社区的各种新近言论～