Re: [GIT PULL] tracing: Updates for 7.2

[Steven Rostedt <rostedt@goodmis.org>]

On Sun, 21 Jun 2026 13:51:30 -0700
Linus Torvalds <torvalds@linux-foundation.org> wrote:

> 
> First you say that it's for a debugging patch that adds the
> trace_printk() locally and never makes it into the tree, which
> explains why nobody else wants to see that thing.

Who is that nobody? I know you don't use trace_printk() at all, but I
would love to have a survey of *all* kernel developers to find out the
percentage that find it useful.

You seem to be of the mind set "I don't think it's useful, so nobody
should think it's useful". Just like you did with Link tags that point
to patches.

> 
> And now you say the problem is that you have to remember to not commit
> the header you added.

It's not the main problem, it's just one of many things that can
happen. But yeah, it's not a big deal.

> 
> JUST LIKE THAT WHOLE trace_printk() that was apparently all just local
> and never committed either.

There's been cases of trace_printk() ending up accidentally in
production. The reason to not allow it in production is because it
writes to the main tracing buffer and it's always on. If it was
allowed, every subsystem would use it and then when you want to debug
something you have to fight the noise of everyone else's trace_printk()
when you want to see yours. It would also make trace events useless.

Thus, a common workflow (and this is what others have told me they do,
I personally don't do this) is to use trace_printk() to find out what
is useful to track for debugging. Then, if important data was traced,
they would turn it into a trace_event. Trace events are basically
trace_printk()s but in a proper form.

On my Fedora laptop:

 $ sudo cat /sys/kernel/tracing/available_events | wc -l
2719

Thus trace_events are very commonly used, which are just
trace_printk()s that you can individually enable and disable.

> 
> So in your magical world, adding the trace_printk() isn't a problem.
> Spending effort debugging things that are hard to reproduce isn't a
> problem. And remembering to not commit said debug code is apparently
> also a non-issue.
> 
> But that extra #include is suddenly a huge problem both to add in the
> first place - oh woe, how it hurts to add that one line to make it
> possible to do those week-long debug sessions - and then to not
> commit.

It is just frustrating when you are focusing on debugging something,
and you go to compile and it errors with "prototype not found". It's
just one more thing added to frustration of fixing code that doesn't
work. I thought we want to make developers lives easier. But since
*you* don't use it, you think it's not an issue.

> 
> This thread has gone from just plain dumb to ridiculous, and I have to
> mute this conversation in order to not get dumber by association.

I 100% agree with getting rid of things in kernel.h. But the little
Makefile change and the config can keep people using trace_printk()
like they have been doing since 2009. Would you at least be OK with
that? It shouldn't make any difference to your workflow, but would make
things easier for others, even if you don't think it would. At least
humor us ;-)

-- Steve