On Sun, Jun 21, 2026 at 05:47:21AM -0400, Steven Rostedt wrote: > On Sun, 21 Jun 2026 05:34:32 -0400 > Steven Rostedt <[email protected]> wrote: > > > Instead of having trace_printk.h included in kernel.h, create a config > > TRACE_PRINTK_DEBUGGING that when set will update the CFLAGS in the > > Makefile to allow developers to add trace_printk() without the need to add > > the include for it. Having it included in the Makefile keeps it from being > > in the dependency chain and it will not waste extra CPU cycles for those > > building the kernel without using trace_printk. > > Bah, I only tested with the config option enabled, and missed some > dependencies with it disabled.
Yes you did. > For instance, rcu.h also uses ftrace_dump() so that too needs to go > into kernel.h. No, it shouldn't. > I also need to add a few more includes to trace_printk.h. > OK, I need to run this through all my tests to find where else I missed > adding the includes. But the idea should hopefully satisfy everyone. If you include it under config in kernel.h, to make the kernel buildable, you need to include trace_printk.h explicitly where it's actually used. IOW, apply my patch v4-7. Then, developers who use trace_printk() on their development machine, will be really frustrated when their debugging code will break client build just because CONFIG_TRACE_PRINTK_DEBUGGING is disabled there. They will spend a day, at best, communicating with remote managers, and end up with adding #include <linux/trace_printk.h> in the files they touch. Is that your plan? If I was one of those developers, the solution would be simple for me: don't use trace_printk() at all. Thanks, Yury
