Re: [RFC] LTTng upstreaming next steps

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

On Tue, 2025-07-15 at 05:24 -0400, Steven Rostedt wrote:
> On Mon, 14 Jul 2025 14:04:38 -0700
> Linus Torvalds <torvalds@linux-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