On Mon, Dec 29, 2025 at 11:17:48AM -0500, Steven Rostedt wrote:

On Sun, 28 Dec 2025 13:31:50 -0800
Andrew Morton [off-list ref] wrote:

quoted

quoted

trace_printk() should be as available to the kernel as printk() is.  

um, why?  trace_printk is used 1% as often as is printk.  Seems
reasonable to include a header file to access such a rarely-used(!) and
specialized thing?

It will waste a lot of kernel developers time. Go to conferences and talk
with developers. trace_printk() is now one of the most common ways to debug
your code. Having to add "#include <linux/trace_printk.h>" in every file
that you use trace_printk() (and after your build fails because you forgot
to include that file **WILL** slow down kernel debugging for hundreds of
developers! It *is* used more than printk() for debugging today. Because
it's fast and can be used in any context (NMI, interrupt handlers, etc).

But sure, if you want to save the few minutes that is added to "make
allyesconfig" by sacrificing minutes of kernel developer's time. Go ahead
and make this change.

I don't know how much you debug and develop today, but lots of people I
talk to at conferences thank me for trace_printk() because it makes
debugging their code so much easier.

The "shotgun" approach is very common. That is, you add:

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

all over your code to find out where things are going wrong. With the
persistent ring buffer, you can even extract that information after a
crash and reboot.

I use trace_printk() all the time for kernel, particularly RCU development.
One of the key usecases I have is dumping traces on panic (with panic on warn
and stop tracing on warn enabled). This is extremely useful since I can add
custom tracing and dump traces when rare conditions occur. I fixed several
bugs with this technique.

I also recommend keeping it convenient to use.

thanks,

 - Joel