Re: [RFC PATCH 2/5] unwind: Export unwind_user symbol to GPL modules

On 2025-07-11 10:02, Steven Rostedt wrote:
> On Fri, 11 Jul 2025 13:38:07 +0200
> Greg KH <[email protected]> wrote:
> 
>> Yes, lttng is a "good citizen" of the kernel community, and yes, it's
>> not merged into the tree, but that's not our issue, and living outside
>> of the tree has it's penalities, both economic and technical.  This is
>> one of those penalities, sorry.
> 
> BTW, when it comes to tracers, being out of tree is actually a huge
> advantage. Tracers, unlike drivers, are only monitoring the kernel. Which
> means it doesn't really rely on the workings of the kernel, so it really
> doesn't get much help from changes made by other kernel developers. Like
> the BPF folks have said keeping BPF programs up to date, isn't that much of
> a burden.
> 
> The huge advantage that LTTng has over perf and ftrace for being out of
> tree is that it controls the ABI between the LTTng kernel side and the user
> space side. LTTng can experiment with new interfaces, and if something
> breaks, it can simply change it and deliver a new tool that includes the
> new module with the update.
> 
> One thing that perf and ftrace struggle with is getting the API correct the
> first time. That's because they have no control over what other tools may use
> their interface. If I expose something that another tool starts to use
> (like powertop) and then I change it to enhance tracing and it breaks that
> tool, that change gets reverted. To make any new update, I have to guess at
> what are all the ways a tool could abuse this interface and also make sure
> it works well into the future when new things come up. There's a lot of
> interfaces I would love to change but can't, simply because they are now
> ABI.
> 
> LTTng doesn't have the burden of worrying about "what other tool may use
> this kernel interface?", and can even change it much later if Mathieu finds
> a better way to do it.

This is indeed one advantage LTTng has: it controls both the kernel
and userspace sides of the software.

I should point out however that since about LTTng 2.7 (2015) we've made
it a project policy to never break the LTTng-modules userspace ABI.
Those ABIs are effectively append-only (with possible gradual
deprecation) to make life easier for distro vendors for which the
userspace vs kernel modules packages are not in sync sometimes.
ABI-breaking changes to LTTng-modules makes packaging of kernel + OOT
modules + userspace tricky for distros. Similarly to the Linux kernel,
our "do not break userspace ABI" policy takes care of this.

So even though LTTng does not _break_ ABIs, it benefits from controlling
what userspace is allowed to interact with it. The fact that we have
an aligned release cycle across LTTng-Tools, the LTTng userspace tracer,
and the LTTng kernel tracer allows us to deprecate ABIs at a faster pace
than what typical kernel ABIs with arbitrary userspace consumers can do.

Thanks,

Mathieu

-- 
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com