Re: [RFC] LTTng upstreaming next steps

[James Bottomley <James.Bottomley@HansenPartnership.com>]

On Tue, 2025-07-15 at 09:16 -0400, Steven Rostedt wrote:
> On Tue, 15 Jul 2025 08:50:08 -0400
> James Bottomley <James.Bottomley@HansenPartnership.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.

I think you know as well as I no investment happens without some
indication of upstream being in favour, particularly for large changes.
So they're not going to invest in doing this on spec because it would
be unmaintainable out of tree and would be way more hassle than simply
having customers reboot as they do today.

> 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().

I don't believe I said that: purpose is not monolithic in open source
because people do things for wildly different reasons which a clever
leader can stitch together into something more synergistically useful.
The cloud vendors would be invested solely for the purpose of being
able to load tracing infrastructure on demand (with the permission of
the tenant) into a running kernel.  They wouldn't care at all about the
symbol export problems of LTTng.  However, working with the cloud
vendors on what they want (and could be persuaded to invest in) would
give you what you wanted: an in-tree consumer for these symbols.

Regards,

James