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: <20250714162750.45b12314@gandalf.local.home>
Date: Mon, 14 Jul 2025 16:27:50 -0400
From: Steven Rostedt <rostedt@...dmis.org>
To: 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 Mon, 14 Jul 2025 13:00:27 -0700
Linus Torvalds <torvalds@...ux-foundation.org> wrote:

> On Mon, 14 Jul 2025 at 12:41, Mathieu Desnoyers
> <mathieu.desnoyers@...icios.com> wrote>
> > A) Bulk upstreaming  
> 
> Honestly, I don't see the point.
> 
> The reason the current tracting infrastructure got merged was that
> people were willing to do it incrementally.
> 
> I was hoping that there would be some kind of eventual merging of the
> different ring buffers etc. That was discussed as a hopeful end goal
> originally, but here were are, decades later, and it never happened.

I'll note that one of the reasons that we couldn't use the LTTng ring
buffer is because the format of the tracing ring buffer and the perf ring
buffer were already exposed to user space and would break tooling if they
were changed. LTTng actually has more features than either the existing in
kernel buffers so it couldn't use the existing buffers without breaking its
own tooling.

> 
> And honestly, I am NOT interested in just having two different tracing models.
> 
> If people need two tracing models, then the other one will be out of
> tree. It's that simple.

It's not that anyone needs two models. It's that there's one model that one
set of people use, and there's another model that another set of people use.
The in-tree tracing (aka ftrace) is designed to be used for kernel
developers. It's quick and easy to use to find issues and is mostly focused
around kernel development. The tracefs directory interface has been a
godsend for embedded developers since it only needs busybox to be useful.

LTTng is more focused toward user admins and is around monitoring how the
system is behaving. It has a different set of tooling and interfaces.

> 
> Because if people haven't been able to agree on common models in the
> decades past, I really don't see the point in maintaining two models
> indefinitely side-by-side in the upstream kernel.
> 
> So as far as I'm concerned, this discussion is not a discussion.
> Either there's a way to merge things incrementally with SHARED
> infrastructure, or there isn't.
> 
> No "two different and disjoint trace buffers".
> 
> No "two different and disjoint trace interfaces".

Although they do have a separate set of buffers and interfaces, the actual
infrastructure (tracepoints, function hooks, etc) is shared.

> 
> And very clearly - based on history - that unification will never happen.

Unfortunately, I think you're right. :-(

-- Steve