Message-ID: <20250711065742.00d6668b@gandalf.local.home>
Date: Fri, 11 Jul 2025 06:57:42 -0400
From: Steven Rostedt <rostedt@...dmis.org>
To: Christoph Hellwig <hch@...radead.org>
Cc: Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
 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


[ Adding the TAB to this as well ]

On Fri, 11 Jul 2025 00:36:28 -0700
Christoph Hellwig <hch@...radead.org> wrote:

> On Wed, Jul 09, 2025 at 05:25:49PM -0400, Mathieu Desnoyers wrote:
> > Allow the unwind_user symbol to be used by GPL modules, for instance
> > LTTng.  
> 
> I don't see a LTTng submission or any other user in this series.
> So the usual prohibition against adding unused exports applies here
> as usual.

I want to bring up this discussion. I understand there's a policy not to
add EXPORT_SYMBOL_GPL() unless there's a current user of it in the kernel
proper. My question is, does this policy have to be draconian?

The LTTng project and specifically its maintainer Mathieu has a long
history of working along side of the Linux kernel and actively adding
enhancements to the code. This is not an Nvidia or VMware situation where
the modules add special secret sauce that they do not want to share. This
is a long standing kernel contributor and maintainer that has proved
himself time and time again to be an asset to the Linux kernel community.

It's not even that LTTng wants to be out of tree. There's been several
attempts to get LTTng merged. But they all failed due to disagreements in
approaches and other aspects of the design. With perf and ftrace already in
the kernel which focus toward helping kernel developers debug their issue,
several maintainers do not see the point of LTTng. But LTTng focuses more
on non kernel developers. Mathieu and I have come to a conclusion that
LTTng and ftrace have two different audiences. And we actively work with
each other to improve both ftrace and LTTng.

LTTng was redesigned to work as a very non-intrusive external kernel module
that could be ported to newer kernels without much pain. This approach has
worked for both Mathieu and the kernel maintainers for several years.

It is not because Mathieu doesn't want LTTng in the kernel that is keeping
it out of the tree. He would very much like it in-tree! LTTng is not in the
kernel because the kernel maintainers themselves have been blocking it. I
do not feel that we should be also add the extra burden to prevent any call
it could use from being EXPORT_SYMBOL_GPL().

Mathieu has been very helpful in the work to develop this deferred unwind
code that will help ftrace, perf and BPF. I would also like it to help
LTTng. The only way to do so is to have an EXPORT_SYMBOL_GPL() for it.

Now you can argue that we need to get LTTng into mainline before it can use
this new work that the maintainer of LTTng has been very involved in to
develop. But that would probably take a long time and from past
experiences, may fail completely. So for now, I am saying that we give
LTTng an exception to the rule that functions can not be
EXPORT_SYMBOL_GPL() unless there's a in-tree kernel module that requires it.

-- Steve

Powered by blists - more mailing lists