linux-kernel - Re: [RFC] LTTng upstreaming next steps

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <699bcae748cbb9663029542f93c9c83bc8a2c029.camel@HansenPartnership.com>
Date: Tue, 15 Jul 2025 11:10:43 -0400
From: James Bottomley <James.Bottomley@...senPartnership.com>
To: Steven Rostedt <rostedt@...dmis.org>
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, 2025-07-15 at 10:50 -0400, Steven Rostedt wrote:
> On Tue, 15 Jul 2025 10:38:34 -0400
> James Bottomley <James.Bottomley@...senPartnership.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.

I didn't say he would ... I said you might be able to persuade the
cloud companies to do it.  That's not to say he (and you) couldn't help
incentivise them that their investment might pay off.

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

Well, if you've no interest in thinking outside the box, by all means
continue banging your head against it until you think your payback has
been achieved ...  I'll go and get the popcorn.

Regards,

James