Re: [PATCH 2/2] tracing: Add CONFIG_TRACE_PRINTK_DEBUGGING to clean up kernel.h

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:

quoted

On Sun, 21 Jun 2026 05:34:32 -0400
Steven Rostedt [off-list ref] wrote:

quoted

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.
 

quoted

For instance, rcu.h also uses ftrace_dump() so that too needs to go
into kernel.h.

No, it shouldn't.

quoted

I also need to add a few more includes to trace_printk.h.

quoted

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