Message-ID: <caf5e94b-5daa-459b-a81b-fadf685c6af1@efficios.com>
Date: Fri, 11 Jul 2025 10:17:38 -0400
From: Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
To: Steven Rostedt <rostedt@...dmis.org>, Greg KH <gregkh@...uxfoundation.org>
Cc: Christoph Hellwig <hch@...radead.org>, linux-kernel@...r.kernel.org,
 Josh Poimboeuf <jpoimboe@...nel.org>, Masami Hiramatsu
 <mhiramat@...nel.org>, Peter Zijlstra <peterz@...radead.org>,
 Ingo Molnar <mingo@...nel.org>, Jiri Olsa <jolsa@...nel.org>,
 Namhyung Kim <namhyung@...nel.org>, Thomas Gleixner <tglx@...utronix.de>,
 Andrii Nakryiko <andrii@...nel.org>, Indu Bhagat <indu.bhagat@...cle.com>,
 "Jose E. Marchesi" <jemarch@....org>,
 Beau Belgrave <beaub@...ux.microsoft.com>, Jens Remus
 <jremus@...ux.ibm.com>, Linus Torvalds <torvalds@...ux-foundation.org>,
 Andrew Morton <akpm@...ux-foundation.org>,
 tech-board-discuss@...ts.linuxfoundation.org
Subject: 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 <gregkh@...uxfoundation.org> 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

Powered by blists - more mailing lists