Re: [PATCH 2/2] tracing: Add CONFIG_TRACE_PRINTK_DEBUGGING to clean up kernel.h
Yury Norov <[email protected]> Sun, 21 Jun 2026 09:39:17 -0400
| Newsgroups | org.kernel.vger.linux-kbuild,org.freedesktop.lists.dri-devel,org.freedesktop.lists.intel-gfx,org.infradead.lists.linux-arm-kernel,org.kernel.vger.kvm,org.kernel.vger.linux-doc,org.kernel.vger.linux-ext4,org.kernel.vger.linux-kernel,org.kernel.vger.linux-nfs,org.kernel.vger.linux-rdma,org.kernel.vger.linux-trace-kernel,org.kernel.vger.linux-usb,org.ozlabs.lists.linuxppc-dev |
|---|---|
| Message-ID | <ajfphe4Z8BrfYoUX@yury> |
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