Re: [RFC] LTTng upstreaming next steps

[Steven Rostedt <rostedt@goodmis.org>]

On Tue, 15 Jul 2025 10:38:34 -0400
James Bottomley <James.Bottomley@HansenPartnership.com> wrote:

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

I think you just pointed out why Mathieu doesn't want to do this huge
update to merge upstream.


> 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

No you didn't say that, but I figured I'd mention it as it was likely
a thought someone may have had when reading your reply ;-)

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

I have no vested interest in it. Mathieu has just been very helpful for
the last several years with reviewing and improving the in-tree tracing
infrastructure (which LTTng received no benefit from), that I'm just
paying back the favor in trying to help him out.

-- Steve