On 2025-12-29 11:17, Steven Rostedt wrote:
On Sun, 28 Dec 2025 13:31:50 -0800
Andrew Morton <[email protected]> wrote:
trace_printk() should be as available to the kernel as printk() is.
um, why? trace_printk is used 1% as often as is printk. Seems
reasonable to include a header file to access such a rarely-used(!) and
specialized thing?
[...]
Yes, it's not in your kernel, but it is in several other people's kernels
as they develop it. And adding a requirement that they need to include a
header file for every place they add it (and then have to remember to
remove that header file when they are done debugging) is going to waste
more precious time that kernel developers don't have much of.
I agree with Steven. trace_printk() needs to stay convenient to use for
kernel developers. Part of this convenience comes from not having to
include additional header files by hand. It has been around for
16 years and documented as such in kernel documentation [1],
LWN articles [2], and conference presentation material. Changing
this would lead to confusion for people trying to use the feature.
I personally use trace_printk() to sprinkle temporary debug-style
trace events in frequently executed kernel code I need to follow
carefully.
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. But please make sure the default stays as it is today:
include the trace printk header by default.
Thanks,
Mathieu
[1] Debugging the kernel using Ftrace - part 1 https://lwn.net/Articles/365835/
[2] Documentation/trace/ftrace.txt
--
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com
