Re: [GIT PULL] tracing: Updates for 7.2

[Steven Rostedt <rostedt@goodmis.org>]

On Fri, 19 Jun 2026 07:35:15 -0700
Linus Torvalds <torvalds@linux-foundation.org> wrote:

> 
> Now, if the same was true for printk(), I'd happily split that into
> some other header too.
> 
> But it isn't.
> 
> Because we live in reality.

I'm talking about using it for debugging and not to print info. In
fact, I try hard to *prevent* people keeping trace_printk() *in* the
kernel code. If you add it, it triggers that nasty banner.

The point of having it in kernel.h is for debugging purposes. That's
probably why printk.h is also there too. Many others use the "shotgun"
approach where they add trace_printk()s all over the place to track down
a bug.

Your patch now requires developers from remembering to add a
#include <linux/trace_printk.h> in every file the touch. Or they may
have to touch kernel.h triggering a full build as well. It moves burden
from people who build the kernel and have to wait a little longer to
developers that now need to remember to add includes that they didn't
need to before!

trace_printk() hardly ever changes, so it should not trigger these
builds on changing kernels. The only reason it was changed this time
was because the compilers now have more warnings about printk formats
that required annotation to trace_printk(). As well as a clean up to
remove a variable from a macro.

When I said people use trace_printk() over printk() I meant I know
several (including myself) the seldom ever use printk for debugging the
kernel. If I need to see what's happening, I use trace_printk().
Because it can be used in any context without worrying about slowing
down the system, and less likely to cause heissenbugs.

-- Steve