On Sun, Jun 21, 2026 at 09:39:17AM -0400, Yury Norov wrote: > 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,
I mean: in kernel.h or in Makefile. > 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
