Re: [GIT PULL] tracing: Updates for 7.2

[Steven Rostedt <steven@rostedt.org>]

On Sat, 20 Jun 2026 17:18:26 -0700
Linus Torvalds <torvalds@linux-foundation.org> wrote:

> 
> Because no, trace_printk() isn't special.

When you have a bug that triggers once every 11 days, due to some
strange race, placing trace_printk()s all over to help you narrow down
*where* to look is super important. trace_printk() has an extremely low
overhead, like 150 ns which keeps the chances of it affecting the races
low. Note, the above scenario was real story another kernel developer
told me about, but that's besides the point.

> 
> Christ, the only reason *you* think it's so special is because it's
> your code and you use it, and the people you interact with use it.

Do you know who the people I interact with are? 100s if not 1000s of
kernel developers! I get my ideas from going to conferences and talking
with people. This isn't me in some silo helping out an internal
corporation with their secret sauce. I was unemployed from April 19th
to June 15th and in that time I paid my own way to go to LSF/MM/BPF to
find out more ways the tracing subsystem can be useful to others!

Hang out more at conferences and talk to your kernel's developers and
get a better idea of what people use. You interface mostly with top
level maintainers. How much are you interfacing with the 1000s of
contributors we have? Tracing has been extremely helpful for new
developers. I've mentored several. How many new developers have you
mentored in the last 5 years? That's a serious question. I don't know
if you mentor new developers or not. It would be great if you did.

Just last week, someone asked me how I got involved with the Linux
kernel. They said, "It's so big and complex, how did you start?". I
started looking at the kernel code in 1998. It was much simpler back
then. Learning most of the kernel wasn't that difficult compared to
starting development today. I only had to learn things as they came
into existence. Learning about new features that appear over the years
is much easier than coming in fresh and everything is a new feature to
learn.

> 
> But that's not because it's special - the common issue is *you*, not
> trace_printk.
> 

You already had others tell you that they use trace_printk() for
debugging too. It's *not* just me! Ask people. There's been several
times I've had people come up to me at conferences and thank me for
trace_printk().

Heck, trace_prink() was important enough to be included in eBPF for
debugging they programs.

> 
> We're done here. That header gets removed from kernel.h.

I told you I'm 100% fine with removing trace_printk.h from kernel.h if
you are OK with the Makefile solution I posted. Having a
TRACE_PRINTK_DEBUGGING config would not cause any issue for you or
others that don't care about it. I believe it's a proper compromise.

You seem to act like I'm arguing to keep trace_printk.h in kernel.h
after I came up with an alternate solution. Let me add back the
question you asked to the very first line of my reply that you went off
on:

> On Sat, 20 Jun 2026 15:39:25 -0700
> Linus Torvalds <torvalds@linux-foundation.org> wrote:
> 
> > Feel free to try to come up with such a patch.
> > 
> > But honestly, before you do, what is the *advantage* of such a thing?  
> 
> For debugging it is really useful.

You seem to think that comment was about why to keep trace_printk.h in
kernel.h and bother everyone that doesn't use it. No, you asked me what
the advantage of having the Makefile solution was, and that was my answer.

-- Steve