On Tue, Dec 30, 2025 at 09:21:00AM -0500, Mathieu Desnoyers wrote:

On 2025-12-30 03:55, Andy Shevchenko wrote:

quoted

On Mon, Dec 29, 2025 at 05:25:08PM -0500, Mathieu Desnoyers wrote:

...

quoted

One possible compromise would be to move it to its own header file,
and introduce a CONFIG_TRACE_PRINTK Kconfig option (default Y) that
would surround an include from linux/kernel.h with a preprocessor
conditional.

We already have CONFIG_TRACING, and everything in the new
trace_printk.h is conditional on it. We can protect the header in
kernel.h with the same config.

quoted

quoted

But please make sure the default stays as it is today:
include the trace printk header by default.

"by default" where exactly?

Seemingly nowhere.

quoted

The problem is that kernel.h is a total mess and
it's included in a lot of mysterious ways (indirectly),

Yes!

quoted

and in C you _must_
include a header anyway for a custom API, just define *which* one.

This patch series moves the guts of trace_printk into its own header
file, which reduces clutter. So that's already progress. :)

quoted

Based on the Steven's first replies I see a compromise in having it inside
printk.h. If you want to debug something with printf() (in general) the same
header should provide all species. Do you agree?

 
It may sound logical, but I don't like this idea. Printk() is used
for debugging by everyone, but its main goal is to communicate to
userspace and between different parts of the kernel. Notice how all
debugging and development API in linux/pritnk.h is protected with the
corresponding ifdefery. 

Contrary to that, trace_printk() is a purely debugging feature. There's
no use for it after the debugging is done. (Or I missed something?)

Everyone admits that kernel.h is a mess. Particularly, it's a mess of
development and production features. So, moving trace_printk() from an
already messy kernel.h to a less messy printk.h - to me it looks like
spreading the mess.

I don't have a strong opinion about including trace_printk.h from either
kernel.h or printk.h. As long as it's still included by a default kernel
config the same way it has been documented/used since 2009.

Can you please point to the documentation and quote the exact piece
stating that? Git history points to the commit 40ada30f9621f from Ingo
that decouples tracers from DEBUG_KERNEL, and the following 422d3c7a577
from Kosaki that force-enables the new TRACING_SUPPORT regardless of
the DEBUG_KERNEL state.

To me, decoupling tracing from DEBUG_KERNEL looks accidental rather than
intentional. So maybe simply restore that dependency?

Currently, even with tinyconfig, DEBUG_KERNEL is enabled (via EXPERT).
And even if EXPERT and DEBUG_KERNEL are off, tracers are still enabled.
This doesn't look right...

Thanks,
Yury