Message-ID: <20250714062724.6febd9fb@gandalf.local.home>
Date: Mon, 14 Jul 2025 06:27:24 -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

On Sun, 13 Jul 2025 23:39:29 -0700
Christoph Hellwig <hch@...radead.org> wrote:

> On Fri, Jul 11, 2025 at 06:57:42AM -0400, Steven Rostedt wrote:
> > 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?  
> 
> Yes.  Making exception for friends and family is like Austrian law

This has nothing to do with Mathieu being a friend. He's a long time Linux
kernel contributor and has played a key role in developing a new feature
that will help both perf and ftrace, but without the EXPORT_SYMBOL_GPL(),
LTTng can't use it. It's basically saying "thank you Mathieu for helping us
with this new feature, now go F*** off!"

> enforcement and thus errodes the whole principle.  If you think lttng
> is useful help ustreaming it.

That's the entire point. I have no stake in LTTng getting upstream. I just
sympathize with Mathieu as he has been very helpful in improving ftrace. To
me, open source software should work with each other.

Now, I would not block LTTng from getting upstream. I had a conversation
with Mathieu to discuss why it failed last time, and that's because we went
with the approach of trying to merge the features of ftrace and LTTng where
it made sense, and that became way more work than either of us had, and we
found no real benefit from it (besides getting LTTng upstream). It would
require at least 3 or 4 full months of manpower which I don't have time for.

From what Mathieu told me, LTTng's kernel module is 75K SLOC, with 20 years
of development. It already has its own ecosystem. The only practical way
for it to get upstream is if it were to become its own subsystem (like
kernel/lttng).

Who's going to review 75K of SLOC? I don't have the time to. The only
reason I would want LTTng in the kernel is to officially welcome Mathieu
into our community. Other than that, I have no need for LTTng.

What would you recommend Mathieu to do? He's been helping us for several
years and the work he does helps perf and ftrace and other parts of the
kernel (he's helped improve RCU). But to get LTTng upstream, it would take
a massive amount of work. And Mathieu has tried before without success. Why
should he spend all this time to break up the code into reviewable portions
without anyone willing to review it?

As I mentioned before, Mathieu is at a bit of a disadvantage. His customers
are non-kernel developers. But he needs the interest of kernel developers
to review his code. But he can't find anyone willing to do that. He doesn't
want to waste his time trying spending months of work to get LTTng upstream
if there's no guarantee that it will be accepted.

Would be willing to review his work?

-- Steve

Powered by blists - more mailing lists