[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250715091649.3cc933fa@gandalf.local.home>
Date: Tue, 15 Jul 2025 09:16:49 -0400
From: Steven Rostedt <rostedt@...dmis.org>
To: James Bottomley <James.Bottomley@...senPartnership.com>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>, Mathieu Desnoyers
<mathieu.desnoyers@...icios.com>, Steven Rostedt <rostedt@...nel.org>, Greg
Kroah-Hartman <gregkh@...uxfoundation.org>, Christoph Hellwig
<hch@...radead.org>, "Masami Hiramatsu (Google)" <mhiramat@...nel.org>,
Peter Zijlstra <peterz@...radead.org>, Ingo Molnar <mingo@...nel.org>,
Thomas Gleixner <tglx@...utronix.de>, linux-kernel
<linux-kernel@...r.kernel.org>
Subject: Re: [RFC] LTTng upstreaming next steps
On Tue, 15 Jul 2025 08:50:08 -0400
James Bottomley <James.Bottomley@...senPartnership.com> wrote:
> What's wrong with doing this the other way around? i.e. making ftrace
> and perf modules? That way you could legitimately export the symbol
> you're asking about and there would be way less out-of-tree
> disadvantage to LTTng? I know a lot of cloud people who would be
> really happy if the tracing infrastructure were modular because it
> would save us from having to boot different kernels to do in depth
> problem analysis for otherwise locked down environments, so they might
> be willing to invest in upstream development to help you achieve this.
Well, if you can get those cloud people to invest in that work without
causing any regressions, go for it.
But I doubt it would be acceptable to make the ftrace tracing
infrastructure into a module for the sole purpose of allowing LTTng to have
EXPORT_SYMBOL_GPL().
-- Steve
Powered by blists - more mailing lists