Re: [GIT PULL] tracing: Updates for 7.2

[Steven Rostedt]

On Sat, 20 Jun 2026 15:39:25 -0700
Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> 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.

> 
> Because you seem to think that "trace_printk()" and "printk()" are the same.
> 
> They really aren't.

I do not in any way think they are the same. To me, printk() is used
for information to the console for various production messages, whereas
trace_printk() is used when you have that nasty bug that you don't know
exactly where it is. trace_printk() should never be used in a
production environment.

When I (and many others) use trace_printk() to debug, we basically use
the "shotgun" approach. That is, we add trace_printk() all over the
place to see where the bug occurs. This could be for 10s of files.
Having to add an include to each one of these files is a burden and
adds to the frustration when you are debugging something that doesn't
work. You just want to add trace_printk() in places to see where the
bug triggers.

A lot of times, all I add is:

	trace_printk("%s:%d\n", __func__, __LINE__):

and cut and paste that in several locations in several files between if
statements. I may even add:

	if (bad_condition())
		tracing_off();

Which will disable tracing when the bad condition is detected. Then I
can look at the trace to see all the prints up to the bug. This is
*really* useful!!!

I really want to avoid having to add an include for trace_printk when
I'm focusing on just finding were the bug happens.

I'm pretty sure others on the Cc list have the same use case.

I totally sympathize with getting rid of junk out of kernel.h (and
possibly getting rid of kernel.h altogether) but I also want to keep
this debugging ability around.

-- Steve