On Mon, Dec 29, 2025 at 11:17:48AM -0500, Steven Rostedt wrote: > On Sun, 28 Dec 2025 13:31:50 -0800 > Andrew Morton <[email protected]> wrote: > > > > 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
