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: <9f6700d1fb62da8ce633f755b0c9e2d5c2704825.camel@HansenPartnership.com>
Date: Tue, 15 Jul 2025 08:50:08 -0400
From: James Bottomley <James.Bottomley@...senPartnership.com>
To: Steven Rostedt <rostedt@...dmis.org>, Linus Torvalds
	 <torvalds@...ux-foundation.org>
Cc: 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 05:24 -0400, Steven Rostedt wrote:
> On Mon, 14 Jul 2025 14:04:38 -0700
> Linus Torvalds <torvalds@...ux-foundation.org> wrote:
[...]
> > If people can unify this and merge it incrementally, that's one
> > thing.
> > 
> > Until then, you're just making stuff up.
> > 
> > "Show me the code", in other words.
> 
> We'd love to, but how is one to merge code in incremental steps when
> they are not allowed to use the current infrastructure?
> 
> LTTng being out of tree means it is only allowed to use
> EXPORT_SYMBOL_GPL() functions as it must be a module. Perf, ftrace
> and BPF are all 100% in-tree and has no modules so they do not
> require any EXPORT_SYMBOL_GPL() to use the current infrastructure.
> 
> This is the main difference between an external tracer and an
> external driver. That's because other in-tree drivers and file
> systems all have a module component. If ftrace, perf and BPF were
> modules, it would require the infrastructure they use to all be
> defined as EXPORT_SYMBOL_GPL().  This makes LTTng have a huge
> disadvantage as those are not modules and the interface they use are
> not exported.  This makes LTTng have a huge disadvantage as those are
> not modules and the interface they use are not exported.

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.

Regards,

James