The trace_printk.h header is debugging-only by nature, but now it's
included by almost every compilation unit via kernel.h.
Removing trace_printk.h saves 1.5-2% of compilation time on my
Ubuntu-derived x86_64/localyesconfig.
There's ~30 files in the codebase, requiring trace_printk.h for
non-debugging reasons: mostly to disable tracing on panic or under
similar conditions. Include the header for those explicitly.
This implicitly decouples linux/kernel.h and linux/instruction_pointer.h
as well, because it has been isolated to trace_printk.h early in the
series.
Signed-off-by: Yury Norov (NVIDIA) <yury.norov@gmail.com>
---
arch/powerpc/kvm/book3s_xics.c | 1 +
arch/powerpc/xmon/xmon.c | 1 +
arch/s390/kernel/ipl.c | 1 +
arch/s390/kernel/machine_kexec.c | 1 +
drivers/gpu/drm/i915/gt/intel_gtt.h | 1 +
drivers/gpu/drm/i915/i915_gem.h | 1 +
drivers/hwtracing/stm/dummy_stm.c | 1 +
drivers/infiniband/hw/hfi1/trace_dbg.h | 1 +
drivers/tty/sysrq.c | 1 +
drivers/usb/early/xhci-dbc.c | 1 +
fs/ext4/inline.c | 1 +
include/linux/kernel.h | 1 -
include/linux/sunrpc/debug.h | 1 +
kernel/debug/debug_core.c | 1 +
kernel/panic.c | 1 +
kernel/rcu/rcu.h | 1 +
kernel/rcu/rcutorture.c | 1 +
kernel/trace/error_report-traces.c | 1 +
kernel/trace/ring_buffer_benchmark.c | 1 +
kernel/trace/trace.c | 1 +
kernel/trace/trace_benchmark.c | 1 +
kernel/trace/trace_events_trigger.c | 1 +
kernel/trace/trace_functions.c | 1 +
kernel/trace/trace_printk.c | 1 +
kernel/trace/trace_selftest.c | 1 +
lib/sys_info.c | 1 +
samples/fprobe/fprobe_example.c | 1 +
samples/ftrace/ftrace-direct-modify.c | 1 +
samples/ftrace/ftrace-direct-multi-modify.c | 1 +
samples/ftrace/ftrace-direct-multi.c | 1 +
samples/ftrace/ftrace-direct-too.c | 1 +
samples/ftrace/ftrace-direct.c | 1 +
samples/trace_printk/trace-printk.c | 1 +
sound/hda/common/sysfs.c | 1 +
34 files changed, 33 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/kvm/book3s_xics.c b/arch/powerpc/kvm/book3s_xics.c
index 589a8f257120..8f8cfc8648c6 100644
--- a/arch/powerpc/kvm/book3s_xics.c
+++ b/arch/powerpc/kvm/book3s_xics.c
@@ -20,6 +20,7 @@
#include <asm/time.h>
#include <linux/seq_file.h>
+#include <linux/trace_printk.h>
#include "book3s_xics.h"
diff --git a/arch/powerpc/xmon/xmon.c b/arch/powerpc/xmon/xmon.c
index cb3a3244ae6f..f5cf6d807aeb 100644
--- a/arch/powerpc/xmon/xmon.c
+++ b/arch/powerpc/xmon/xmon.c
@@ -27,6 +27,7 @@
#include <linux/highmem.h>
#include <linux/security.h>
#include <linux/debugfs.h>
+#include <linux/trace_printk.h>
#include <asm/ptrace.h>
#include <asm/smp.h>
diff --git a/arch/s390/kernel/ipl.c b/arch/s390/kernel/ipl.c
index dcdc7e274848..55ac9c9eeb36 100644
--- a/arch/s390/kernel/ipl.c
+++ b/arch/s390/kernel/ipl.c
@@ -20,6 +20,7 @@
#include <linux/gfp.h>
#include <linux/crash_dump.h>
#include <linux/debug_locks.h>
+#include <linux/trace_printk.h>
#include <linux/vmalloc.h>
#include <asm/asm-extable.h>
#include <asm/machine.h>
diff --git a/arch/s390/kernel/machine_kexec.c b/arch/s390/kernel/machine_kexec.c
index baeb3dcfc1c8..668d8444b02b 100644
--- a/arch/s390/kernel/machine_kexec.c
+++ b/arch/s390/kernel/machine_kexec.c
@@ -14,6 +14,7 @@
#include <linux/ftrace.h>
#include <linux/debug_locks.h>
#include <linux/cpufeature.h>
+#include <linux/trace_printk.h>
#include <asm/guarded_storage.h>
#include <asm/machine.h>
#include <asm/pfault.h>
diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.h b/drivers/gpu/drm/i915/gt/intel_gtt.h
index 9d3a3ad567a0..3f6d78a7ccea 100644
--- a/drivers/gpu/drm/i915/gt/intel_gtt.h
+++ b/drivers/gpu/drm/i915/gt/intel_gtt.h
@@ -22,6 +22,7 @@
#include <linux/pagevec.h>
#include <linux/scatterlist.h>
#include <linux/workqueue.h>
+#include <linux/trace_printk.h>
#include <drm/drm_mm.h>
diff --git a/drivers/gpu/drm/i915/i915_gem.h b/drivers/gpu/drm/i915/i915_gem.h
index 20b3cb29cfff..549fdeaf4508 100644
--- a/drivers/gpu/drm/i915/i915_gem.h
+++ b/drivers/gpu/drm/i915/i915_gem.h
@@ -27,6 +27,7 @@
#include <linux/bug.h>
#include <linux/types.h>
+#include <linux/trace_printk.h>
#include <drm/drm_drv.h>
diff --git a/drivers/hwtracing/stm/dummy_stm.c b/drivers/hwtracing/stm/dummy_stm.c
index 38528ffdc0b3..8464401756f3 100644
--- a/drivers/hwtracing/stm/dummy_stm.c
+++ b/drivers/hwtracing/stm/dummy_stm.c
@@ -12,6 +12,7 @@
#include <linux/module.h>
#include <linux/slab.h>
#include <linux/stm.h>
+#include <linux/trace_printk.h>
#include <uapi/linux/stm.h>
static ssize_t notrace
diff --git a/drivers/infiniband/hw/hfi1/trace_dbg.h b/drivers/infiniband/hw/hfi1/trace_dbg.h
index 58304b91380f..d7c08190d816 100644
--- a/drivers/infiniband/hw/hfi1/trace_dbg.h
+++ b/drivers/infiniband/hw/hfi1/trace_dbg.h
@@ -8,6 +8,7 @@
#include <linux/tracepoint.h>
#include <linux/trace_seq.h>
+#include <linux/trace_printk.h>
#include "hfi.h"
diff --git a/drivers/tty/sysrq.c b/drivers/tty/sysrq.c
index 1f78b0db3b25..72b2555c2bb8 100644
--- a/drivers/tty/sysrq.c
+++ b/drivers/tty/sysrq.c
@@ -51,6 +51,7 @@
#include <linux/syscalls.h>
#include <linux/of.h>
#include <linux/rcupdate.h>
+#include <linux/trace_printk.h>
#include <asm/ptrace.h>
#include <asm/irq_regs.h>
diff --git a/drivers/usb/early/xhci-dbc.c b/drivers/usb/early/xhci-dbc.c
index 41118bba9197..dce1e2a3e180 100644
--- a/drivers/usb/early/xhci-dbc.c
+++ b/drivers/usb/early/xhci-dbc.c
@@ -22,6 +22,7 @@
#include <linux/delay.h>
#include <linux/kthread.h>
#include <linux/usb/xhci-dbgp.h>
+#include <linux/trace_printk.h>
#include "../host/xhci.h"
#include "xhci-dbc.h"
diff --git a/fs/ext4/inline.c b/fs/ext4/inline.c
index 1f6bc05593df..d15faa78eb07 100644
--- a/fs/ext4/inline.c
+++ b/fs/ext4/inline.c
@@ -9,6 +9,7 @@
#include <linux/namei.h>
#include <linux/iversion.h>
#include <linux/sched/mm.h>
+#include <linux/trace_printk.h>
#include "ext4_jbd2.h"
#include "ext4.h"
diff --git a/include/linux/kernel.h b/include/linux/kernel.h
index a377335e01da..c48f7109bb2a 100644
--- a/include/linux/kernel.h
+++ b/include/linux/kernel.h
@@ -32,7 +32,6 @@
#include <linux/build_bug.h>
#include <linux/sprintf.h>
#include <linux/static_call_types.h>
-#include <linux/trace_printk.h>
#include <linux/util_macros.h>
#include <linux/wordpart.h>
diff --git a/include/linux/sunrpc/debug.h b/include/linux/sunrpc/debug.h
index 891f6173c951..db2b572505f5 100644
--- a/include/linux/sunrpc/debug.h
+++ b/include/linux/sunrpc/debug.h
@@ -9,6 +9,7 @@
#ifndef _LINUX_SUNRPC_DEBUG_H_
#define _LINUX_SUNRPC_DEBUG_H_
+#include <linux/trace_printk.h>
#include <uapi/linux/sunrpc/debug.h>
/*
diff --git a/kernel/debug/debug_core.c b/kernel/debug/debug_core.c
index 0b9495187fba..e9209afc78aa 100644
--- a/kernel/debug/debug_core.c
+++ b/kernel/debug/debug_core.c
@@ -53,6 +53,7 @@
#include <linux/rcupdate.h>
#include <linux/irq.h>
#include <linux/security.h>
+#include <linux/trace_printk.h>
#include <asm/cacheflush.h>
#include <asm/byteorder.h>
diff --git a/kernel/panic.c b/kernel/panic.c
index 0d52210a9e2b..b9e1ff90c637 100644
--- a/kernel/panic.c
+++ b/kernel/panic.c
@@ -37,6 +37,7 @@
#include <linux/context_tracking.h>
#include <linux/seq_buf.h>
#include <linux/sys_info.h>
+#include <linux/trace_printk.h>
#include <trace/events/error_report.h>
#include <asm/sections.h>
diff --git a/kernel/rcu/rcu.h b/kernel/rcu/rcu.h
index 9cf01832a6c3..1c8f5765ba8b 100644
--- a/kernel/rcu/rcu.h
+++ b/kernel/rcu/rcu.h
@@ -12,6 +12,7 @@
#include <linux/slab.h>
#include <trace/events/rcu.h>
+#include <linux/trace_printk.h>
/*
* Grace-period counter management.
diff --git a/kernel/rcu/rcutorture.c b/kernel/rcu/rcutorture.c
index 07e51974b06b..c2f859c20ca7 100644
--- a/kernel/rcu/rcutorture.c
+++ b/kernel/rcu/rcutorture.c
@@ -48,6 +48,7 @@
#include <linux/tick.h>
#include <linux/rcupdate_trace.h>
#include <linux/nmi.h>
+#include <linux/trace_printk.h>
#include "rcu.h"
diff --git a/kernel/trace/error_report-traces.c b/kernel/trace/error_report-traces.c
index f89792c25b11..6a3c59f39ea2 100644
--- a/kernel/trace/error_report-traces.c
+++ b/kernel/trace/error_report-traces.c
@@ -7,5 +7,6 @@
#define CREATE_TRACE_POINTS
#include <trace/events/error_report.h>
+#include <linux/trace_printk.h>
EXPORT_TRACEPOINT_SYMBOL_GPL(error_report_end);
diff --git a/kernel/trace/ring_buffer_benchmark.c b/kernel/trace/ring_buffer_benchmark.c
index 593e3b59e42e..b977ee0879c1 100644
--- a/kernel/trace/ring_buffer_benchmark.c
+++ b/kernel/trace/ring_buffer_benchmark.c
@@ -10,6 +10,7 @@
#include <uapi/linux/sched/types.h>
#include <linux/module.h>
#include <linux/ktime.h>
+#include <linux/trace_printk.h>
#include <asm/local.h>
struct rb_page {
diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
index 57f24e2cd19c..0684cc6b17c5 100644
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -53,6 +53,7 @@
#include <linux/sort.h>
#include <linux/io.h> /* vmap_page_range() */
#include <linux/fs_context.h>
+#include <linux/trace_printk.h>
#include <asm/setup.h> /* COMMAND_LINE_SIZE */
diff --git a/kernel/trace/trace_benchmark.c b/kernel/trace/trace_benchmark.c
index e19c32f2a938..740b49c493db 100644
--- a/kernel/trace/trace_benchmark.c
+++ b/kernel/trace/trace_benchmark.c
@@ -3,6 +3,7 @@
#include <linux/module.h>
#include <linux/kthread.h>
#include <linux/trace_clock.h>
+#include <linux/trace_printk.h>
#define CREATE_TRACE_POINTS
#include "trace_benchmark.h"
diff --git a/kernel/trace/trace_events_trigger.c b/kernel/trace/trace_events_trigger.c
index 06b75bcfc7b8..1c1420a4c429 100644
--- a/kernel/trace/trace_events_trigger.c
+++ b/kernel/trace/trace_events_trigger.c
@@ -12,6 +12,7 @@
#include <linux/mutex.h>
#include <linux/slab.h>
#include <linux/rculist.h>
+#include <linux/trace_printk.h>
#include "trace.h"
diff --git a/kernel/trace/trace_functions.c b/kernel/trace/trace_functions.c
index c12795c2fb39..ec725f8b2343 100644
--- a/kernel/trace/trace_functions.c
+++ b/kernel/trace/trace_functions.c
@@ -16,6 +16,7 @@
#include <linux/ftrace.h>
#include <linux/slab.h>
#include <linux/fs.h>
+#include <linux/trace_printk.h>
#include "trace.h"
diff --git a/kernel/trace/trace_printk.c b/kernel/trace/trace_printk.c
index 29f6e95439b6..e49609c97496 100644
--- a/kernel/trace/trace_printk.c
+++ b/kernel/trace/trace_printk.c
@@ -16,6 +16,7 @@
#include <linux/ctype.h>
#include <linux/list.h>
#include <linux/slab.h>
+#include <linux/trace_printk.h>
#include "trace.h"
diff --git a/kernel/trace/trace_selftest.c b/kernel/trace/trace_selftest.c
index d88c44f1dfa5..b6aa5c92f079 100644
--- a/kernel/trace/trace_selftest.c
+++ b/kernel/trace/trace_selftest.c
@@ -6,6 +6,7 @@
#include <linux/kthread.h>
#include <linux/delay.h>
#include <linux/slab.h>
+#include <linux/trace_printk.h>
static inline int trace_valid_entry(struct trace_entry *entry)
{
diff --git a/lib/sys_info.c b/lib/sys_info.c
index f32a06ec9ed4..7ded4e7f3671 100644
--- a/lib/sys_info.c
+++ b/lib/sys_info.c
@@ -10,6 +10,7 @@
#include <linux/sched/debug.h>
#include <linux/string.h>
#include <linux/sysctl.h>
+#include <linux/trace_printk.h>
#include <linux/sys_info.h>
diff --git a/samples/fprobe/fprobe_example.c b/samples/fprobe/fprobe_example.c
index bfe98ce826f3..dfebb1cefb2c 100644
--- a/samples/fprobe/fprobe_example.c
+++ b/samples/fprobe/fprobe_example.c
@@ -17,6 +17,7 @@
#include <linux/fprobe.h>
#include <linux/sched/debug.h>
#include <linux/slab.h>
+#include <linux/trace_printk.h>
#define BACKTRACE_DEPTH 16
#define MAX_SYMBOL_LEN 4096
diff --git a/samples/ftrace/ftrace-direct-modify.c b/samples/ftrace/ftrace-direct-modify.c
index da3a9f2091f5..cb6989f52167 100644
--- a/samples/ftrace/ftrace-direct-modify.c
+++ b/samples/ftrace/ftrace-direct-modify.c
@@ -2,6 +2,7 @@
#include <linux/module.h>
#include <linux/kthread.h>
#include <linux/ftrace.h>
+#include <linux/trace_printk.h>
#if !defined(CONFIG_ARM64) && !defined(CONFIG_PPC32)
#include <asm/asm-offsets.h>
#endif
diff --git a/samples/ftrace/ftrace-direct-multi-modify.c b/samples/ftrace/ftrace-direct-multi-modify.c
index 8f7986d698d8..1b24d53c34c2 100644
--- a/samples/ftrace/ftrace-direct-multi-modify.c
+++ b/samples/ftrace/ftrace-direct-multi-modify.c
@@ -2,6 +2,7 @@
#include <linux/module.h>
#include <linux/kthread.h>
#include <linux/ftrace.h>
+#include <linux/trace_printk.h>
#if !defined(CONFIG_ARM64) && !defined(CONFIG_PPC32)
#include <asm/asm-offsets.h>
#endif
diff --git a/samples/ftrace/ftrace-direct-multi.c b/samples/ftrace/ftrace-direct-multi.c
index db326c81a27d..3c94ecdaf3d5 100644
--- a/samples/ftrace/ftrace-direct-multi.c
+++ b/samples/ftrace/ftrace-direct-multi.c
@@ -4,6 +4,7 @@
#include <linux/mm.h> /* for handle_mm_fault() */
#include <linux/ftrace.h>
#include <linux/sched/stat.h>
+#include <linux/trace_printk.h>
#if !defined(CONFIG_ARM64) && !defined(CONFIG_PPC32)
#include <asm/asm-offsets.h>
#endif
diff --git a/samples/ftrace/ftrace-direct-too.c b/samples/ftrace/ftrace-direct-too.c
index 3d0fa260332d..e4c26db202ce 100644
--- a/samples/ftrace/ftrace-direct-too.c
+++ b/samples/ftrace/ftrace-direct-too.c
@@ -3,6 +3,7 @@
#include <linux/mm.h> /* for handle_mm_fault() */
#include <linux/ftrace.h>
+#include <linux/trace_printk.h>
#if !defined(CONFIG_ARM64) && !defined(CONFIG_PPC32)
#include <asm/asm-offsets.h>
#endif
diff --git a/samples/ftrace/ftrace-direct.c b/samples/ftrace/ftrace-direct.c
index 956834b0d19a..01f3512aec50 100644
--- a/samples/ftrace/ftrace-direct.c
+++ b/samples/ftrace/ftrace-direct.c
@@ -3,6 +3,7 @@
#include <linux/sched.h> /* for wake_up_process() */
#include <linux/ftrace.h>
+#include <linux/trace_printk.h>
#if !defined(CONFIG_ARM64) && !defined(CONFIG_PPC32)
#include <asm/asm-offsets.h>
#endif
diff --git a/samples/trace_printk/trace-printk.c b/samples/trace_printk/trace-printk.c
index cfc159580263..4fc58844aff1 100644
--- a/samples/trace_printk/trace-printk.c
+++ b/samples/trace_printk/trace-printk.c
@@ -2,6 +2,7 @@
#include <linux/module.h>
#include <linux/kthread.h>
#include <linux/irq_work.h>
+#include <linux/trace_printk.h>
/* Must not be static to force gcc to consider these non constant */
char *trace_printk_test_global_str =
diff --git a/sound/hda/common/sysfs.c b/sound/hda/common/sysfs.c
index f8c8483fd5e5..ac382f7063dc 100644
--- a/sound/hda/common/sysfs.c
+++ b/sound/hda/common/sysfs.c
@@ -19,6 +19,7 @@
#include "hda_local.h"
#include <sound/hda_hwdep.h>
#include <sound/minors.h>
+#include <linux/trace_printk.h>
/* hint string pair */
struct hda_hint {
--
2.43.0On Thu, Dec 25, 2025 at 12:09:29PM -0500, Yury Norov (NVIDIA) wrote: > The trace_printk.h header is debugging-only by nature, but now it's > included by almost every compilation unit via kernel.h. > > Removing trace_printk.h saves 1.5-2% of compilation time on my > Ubuntu-derived x86_64/localyesconfig. > > There's ~30 files in the codebase, requiring trace_printk.h for > non-debugging reasons: mostly to disable tracing on panic or under > similar conditions. Include the header for those explicitly. > > This implicitly decouples linux/kernel.h and linux/instruction_pointer.h > as well, because it has been isolated to trace_printk.h early in the > series. ... > #include <linux/pagevec.h> > #include <linux/scatterlist.h> > #include <linux/workqueue.h> > +#include <linux/trace_printk.h> I believe 't' is followed by 'w' and not vise versa. ... > index 20b3cb29cfff..549fdeaf4508 100644 > --- a/drivers/gpu/drm/i915/i915_gem.h > +++ b/drivers/gpu/drm/i915/i915_gem.h > @@ -27,6 +27,7 @@ > > #include <linux/bug.h> > #include <linux/types.h> > +#include <linux/trace_printk.h> In the similar way 'r' then 'y'. ... Please, double check these and the rest. -- With Best Regards, Andy Shevchenko
On Thu, 25 Dec 2025 12:09:29 -0500 "Yury Norov (NVIDIA)" <yury.norov@gmail.com> wrote: > The trace_printk.h header is debugging-only by nature, but now it's > included by almost every compilation unit via kernel.h. > > Removing trace_printk.h saves 1.5-2% of compilation time on my > Ubuntu-derived x86_64/localyesconfig. > > There's ~30 files in the codebase, requiring trace_printk.h for > non-debugging reasons: mostly to disable tracing on panic or under > similar conditions. Include the header for those explicitly. > > This implicitly decouples linux/kernel.h and linux/instruction_pointer.h > as well, because it has been isolated to trace_printk.h early in the > series. > > Signed-off-by: Yury Norov (NVIDIA) <yury.norov@gmail.com> I'm still against this patch. It means every time someone adds trace_printk() they need to add the header for it. trace_printk() should be as available to the kernel as printk() is. If there's a place that one can add printk() without adding a header, then they should be able to add trace_printk() to that same location without adding any header. If that's not the case, then I'm adding an official Nacked-by: Steven Rostedt <rostedt@goodmis.org> I'm fine for trying other ways to speed up the compilation, but removing full access to trace_printk() isn't one of them. -- Steve
On Fri, 26 Dec 2025 11:58:48 -0500 Steven Rostedt <rostedt@goodmis.org> wrote: > On Thu, 25 Dec 2025 12:09:29 -0500 > "Yury Norov (NVIDIA)" <yury.norov@gmail.com> wrote: > > > The trace_printk.h header is debugging-only by nature, but now it's > > included by almost every compilation unit via kernel.h. > > > > Removing trace_printk.h saves 1.5-2% of compilation time on my > > Ubuntu-derived x86_64/localyesconfig. > > > > There's ~30 files in the codebase, requiring trace_printk.h for > > non-debugging reasons: mostly to disable tracing on panic or under > > similar conditions. Include the header for those explicitly. > > > > This implicitly decouples linux/kernel.h and linux/instruction_pointer.h > > as well, because it has been isolated to trace_printk.h early in the > > series. > > > > Signed-off-by: Yury Norov (NVIDIA) <yury.norov@gmail.com> > > I'm still against this patch. It means every time someone adds > trace_printk() they need to add the header for it. > > 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?
On Sun, 28 Dec 2025 13:31:50 -0800
Andrew Morton <akpm@linux-foundation.org> 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?
It will waste a lot of kernel developers time. Go to conferences and talk
with developers. trace_printk() is now one of the most common ways to debug
your code. Having to add "#include <linux/trace_printk.h>" in every file
that you use trace_printk() (and after your build fails because you forgot
to include that file **WILL** slow down kernel debugging for hundreds of
developers! It *is* used more than printk() for debugging today. Because
it's fast and can be used in any context (NMI, interrupt handlers, etc).
But sure, if you want to save the few minutes that is added to "make
allyesconfig" by sacrificing minutes of kernel developer's time. Go ahead
and make this change.
I don't know how much you debug and develop today, but lots of people I
talk to at conferences thank me for trace_printk() because it makes
debugging their code so much easier.
The "shotgun" approach is very common. That is, you add:
trace_printk("%s:%d\n", __func__, __LINE__);
all over your code to find out where things are going wrong. With the
persistent ring buffer, you can even extract that information after a
crash and reboot.
There's very few instances of it in the kernel because I made it that way.
If you add a trace_printk() in the kernel, you get the banner:
**********************************************************
** NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE **
** **
** trace_printk() being used. Allocating extra memory. **
** **
** This means that this is a DEBUG kernel and it is **
** unsafe for production use. **
** **
** If you see this message and you are not debugging **
** the kernel, report this immediately to your vendor! **
** **
** NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE **
**********************************************************
in your dmesg.
I've been recommending people that if you find a "trace_printk()" useful,
you should convert it into a normal TRACE_EVENT() for submission. Which
many developers have done.
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.
-- Steve
On Mon, Dec 29, 2025 at 11:17:48AM -0500, Steven Rostedt wrote:
> On Sun, 28 Dec 2025 13:31:50 -0800
> Andrew Morton <akpm@linux-foundation.org> 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?
>
> It will waste a lot of kernel developers time. Go to conferences and talk
> with developers. trace_printk() is now one of the most common ways to debug
> your code. Having to add "#include <linux/trace_printk.h>" in every file
> that you use trace_printk() (and after your build fails because you forgot
> to include that file **WILL** slow down kernel debugging for hundreds of
> developers! It *is* used more than printk() for debugging today. Because
> it's fast and can be used in any context (NMI, interrupt handlers, etc).
>
> But sure, if you want to save the few minutes that is added to "make
> allyesconfig" by sacrificing minutes of kernel developer's time. Go ahead
> and make this change.
>
> I don't know how much you debug and develop today, but lots of people I
> talk to at conferences thank me for trace_printk() because it makes
> debugging their code so much easier.
>
> The "shotgun" approach is very common. That is, you add:
>
> trace_printk("%s:%d\n", __func__, __LINE__);
>
> all over your code to find out where things are going wrong. With the
> persistent ring buffer, you can even extract that information after a
> crash and reboot.
I use trace_printk() all the time for kernel, particularly RCU development.
One of the key usecases I have is dumping traces on panic (with panic on warn
and stop tracing on warn enabled). This is extremely useful since I can add
custom tracing and dump traces when rare conditions occur. I fixed several
bugs with this technique.
I also recommend keeping it convenient to use.
thanks,
- Joel
On Fri, Jan 02, 2026 at 07:50:59PM -0500, Joel Fernandes wrote: > On Mon, Dec 29, 2025 at 11:17:48AM -0500, Steven Rostedt wrote: ... > I use trace_printk() all the time for kernel, particularly RCU development. > One of the key usecases I have is dumping traces on panic (with panic on warn > and stop tracing on warn enabled). This is extremely useful since I can add > custom tracing and dump traces when rare conditions occur. I fixed several > bugs with this technique. > > I also recommend keeping it convenient to use. Okay, you know C, please share your opinion what header is the best to hold the trace_printk.h to be included. -- With Best Regards, Andy Shevchenko
> On Jan 3, 2026, at 7:58 AM, Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote: > > On Fri, Jan 02, 2026 at 07:50:59PM -0500, Joel Fernandes wrote: >> On Mon, Dec 29, 2025 at 11:17:48AM -0500, Steven Rostedt wrote: > > ... > >> I use trace_printk() all the time for kernel, particularly RCU development. >> One of the key usecases I have is dumping traces on panic (with panic on warn >> and stop tracing on warn enabled). This is extremely useful since I can add >> custom tracing and dump traces when rare conditions occur. I fixed several >> bugs with this technique. >> >> I also recommend keeping it convenient to use. > > Okay, you know C, please share your opinion what header is the best to hold the > trace_printk.h to be included. I do not think it is necessary to move it. - Joel > > -- > With Best Regards, > Andy Shevchenko > >
On Sat, Jan 03, 2026 at 03:36:44PM +0000, Joel Fernandes wrote: > > On Jan 3, 2026, at 7:58 AM, Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote: > > On Fri, Jan 02, 2026 at 07:50:59PM -0500, Joel Fernandes wrote: > >> On Mon, Dec 29, 2025 at 11:17:48AM -0500, Steven Rostedt wrote: ... > >> I use trace_printk() all the time for kernel, particularly RCU development. > >> One of the key usecases I have is dumping traces on panic (with panic on warn > >> and stop tracing on warn enabled). This is extremely useful since I can add > >> custom tracing and dump traces when rare conditions occur. I fixed several > >> bugs with this technique. > >> > >> I also recommend keeping it convenient to use. > > > > Okay, you know C, please share your opinion what header is the best to hold the > > trace_printk.h to be included. > > I do not think it is necessary to move it. I'm not talking about move, I'm talking about the C 101 thingy. Any custom API should be included before use, otherwise compiler won't see it. Which header do you want to include to have this API being provided? Note, it's really bad situation right now with the header to be included implicitly via non-obvious or obscure path. The discussion moved as far as I see it towards the finding a good place for the trace_printk.h. -- With Best Regards, Andy Shevchenko
On Sun, 4 Jan 2026 02:20:55 +0200 Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote: > > > > I do not think it is necessary to move it. > > I'm not talking about move, I'm talking about the C 101 thingy. Any custom API > should be included before use, otherwise compiler won't see it. Which header do > you want to include to have this API being provided? Note, it's really bad > situation right now with the header to be included implicitly via non-obvious > or obscure path. The discussion moved as far as I see it towards the finding a > good place for the trace_printk.h. It's not a normal API. It's for debugging the kernel. Thus it should be available everywhere without having to add a header. Hence, the best place to include trace_printk.h, is in kernel.h. I'm thinking that my proposed config option is the best solution now. For those that do not care about debugging the kernel, you enable the "HIDE_TRACE_PRINTK" config so that your builds will be "quicker". But for everyone else, it will not slow down their workflow when they need to debug code. -- Steve
On Mon, Jan 05, 2026 at 11:39:02AM -0500, Steven Rostedt wrote: > On Sun, 4 Jan 2026 02:20:55 +0200 > Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote: > > > > I do not think it is necessary to move it. > > > > I'm not talking about move, I'm talking about the C 101 thingy. Any custom API > > should be included before use, otherwise compiler won't see it. Which header do > > you want to include to have this API being provided? Note, it's really bad > > situation right now with the header to be included implicitly via non-obvious > > or obscure path. The discussion moved as far as I see it towards the finding a > > good place for the trace_printk.h. > > It's not a normal API. It's for debugging the kernel. Thus it should be > available everywhere without having to add a header. Hence, the best place > to include trace_printk.h, is in kernel.h. With the above it sounds like you rather want to see it being included as kconfig.h (to every single file). But I disagree on that approach, why do we need this header to pollute every file even if I do not debug the thing? But since the current state is kernel.h, the status quo is to keep it there for now. > I'm thinking that my proposed config option is the best solution now. For > those that do not care about debugging the kernel, you enable the > "HIDE_TRACE_PRINTK" config so that your builds will be "quicker". But for > everyone else, it will not slow down their workflow when they need to debug > code. Maybe, to keep a status quo. Seems for now the compromise is to have it split and be included back to kernel.h and later we can decide if the option or other variants can give a better granularity for people who are not lazy to remember and add a header if they need to debug stuff. Yury, I think in v5 you need to drop this patch, otherwise we won't move further. -- With Best Regards, Andy Shevchenko
On Mon, Jan 05, 2026 at 08:02:39PM +0200, Andy Shevchenko wrote: > On Mon, Jan 05, 2026 at 11:39:02AM -0500, Steven Rostedt wrote: > > On Sun, 4 Jan 2026 02:20:55 +0200 > > Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote: > > > > > > I do not think it is necessary to move it. > > > > > > I'm not talking about move, I'm talking about the C 101 thingy. Any custom API > > > should be included before use, otherwise compiler won't see it. Which header do > > > you want to include to have this API being provided? Note, it's really bad > > > situation right now with the header to be included implicitly via non-obvious > > > or obscure path. The discussion moved as far as I see it towards the finding a > > > good place for the trace_printk.h. > > > > It's not a normal API. It's for debugging the kernel. Thus it should be > > available everywhere without having to add a header. Hence, the best place > > to include trace_printk.h, is in kernel.h. > > With the above it sounds like you rather want to see it being included as > kconfig.h (to every single file). But I disagree on that approach, why do > we need this header to pollute every file even if I do not debug the thing? > > But since the current state is kernel.h, the status quo is to keep it there > for now. > > > I'm thinking that my proposed config option is the best solution now. For > > those that do not care about debugging the kernel, you enable the > > "HIDE_TRACE_PRINTK" config so that your builds will be "quicker". But for > > everyone else, it will not slow down their workflow when they need to debug > > code. > > Maybe, to keep a status quo. +1 > Seems for now the compromise is to have it split and be included back to > kernel.h and later we can decide if the option or other variants can give a > better granularity for people who are not lazy to remember and add a header if > they need to debug stuff. > > Yury, I think in v5 you need to drop this patch, otherwise we won't move further. Not sure we need v5 because the only change is dropping the last patch in the series. But if you prefer - I can send v5.
On Mon, Jan 05, 2026 at 01:07:31PM -0500, Yury Norov wrote: > On Mon, Jan 05, 2026 at 08:02:39PM +0200, Andy Shevchenko wrote: > > On Mon, Jan 05, 2026 at 11:39:02AM -0500, Steven Rostedt wrote: ... > > Yury, I think in v5 you need to drop this patch, otherwise we won't move further. > > Not sure we need v5 because the only change is dropping the last patch > in the series. But if you prefer - I can send v5. It depends on who is going to apply them. For me personally v5 is not needed, but I think there were some tags given in v4? With that it might make some sense to have a v5. -- With Best Regards, Andy Shevchenko
On 1/5/2026 11:39 AM, Steven Rostedt wrote: > On Sun, 4 Jan 2026 02:20:55 +0200 > Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote: > >>> >>> I do not think it is necessary to move it. >> >> I'm not talking about move, I'm talking about the C 101 thingy. Any custom API >> should be included before use, otherwise compiler won't see it. Which header do >> you want to include to have this API being provided? Note, it's really bad >> situation right now with the header to be included implicitly via non-obvious >> or obscure path. The discussion moved as far as I see it towards the finding a >> good place for the trace_printk.h. > > It's not a normal API. It's for debugging the kernel. Thus it should be > available everywhere without having to add a header. Hence, the best place > to include trace_printk.h, is in kernel.h. > > I'm thinking that my proposed config option is the best solution now. For > those that do not care about debugging the kernel, you enable the > "HIDE_TRACE_PRINTK" config so that your builds will be "quicker". But for > everyone else, it will not slow down their workflow when they need to debug > code. 100% agree. We do have people running custom configs for faster builds, so this hide thing could be enabled there assuming those don't care about debug. In other words, "If it aint broke, don't fix it". - Joel
Le 05/01/2026 à 18:11, Joel Fernandes a écrit : > > > On 1/5/2026 11:39 AM, Steven Rostedt wrote: >> On Sun, 4 Jan 2026 02:20:55 +0200 >> Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote: >> >>>> >>>> I do not think it is necessary to move it. >>> >>> I'm not talking about move, I'm talking about the C 101 thingy. Any custom API >>> should be included before use, otherwise compiler won't see it. Which header do >>> you want to include to have this API being provided? Note, it's really bad >>> situation right now with the header to be included implicitly via non-obvious >>> or obscure path. The discussion moved as far as I see it towards the finding a >>> good place for the trace_printk.h. >> >> It's not a normal API. It's for debugging the kernel. Thus it should be >> available everywhere without having to add a header. Hence, the best place >> to include trace_printk.h, is in kernel.h. >> >> I'm thinking that my proposed config option is the best solution now. For >> those that do not care about debugging the kernel, you enable the >> "HIDE_TRACE_PRINTK" config so that your builds will be "quicker". But for >> everyone else, it will not slow down their workflow when they need to debug >> code. > > 100% agree. We do have people running custom configs for faster builds, so this > hide thing could be enabled there assuming those don't care about debug. > > In other words, "If it aint broke, don't fix it". But if I understand correctly, it would save 2% build time. That means 12 secondes on a 10 minutes build. Is it really worth it ? Christophe
On 1/5/2026 1:21 PM, Christophe Leroy (CS GROUP) wrote: > > > Le 05/01/2026 à 18:11, Joel Fernandes a écrit : >> >> >> On 1/5/2026 11:39 AM, Steven Rostedt wrote: >>> On Sun, 4 Jan 2026 02:20:55 +0200 >>> Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote: >>> >>>>> >>>>> I do not think it is necessary to move it. >>>> >>>> I'm not talking about move, I'm talking about the C 101 thingy. Any custom API >>>> should be included before use, otherwise compiler won't see it. Which header do >>>> you want to include to have this API being provided? Note, it's really bad >>>> situation right now with the header to be included implicitly via non-obvious >>>> or obscure path. The discussion moved as far as I see it towards the finding a >>>> good place for the trace_printk.h. >>> >>> It's not a normal API. It's for debugging the kernel. Thus it should be >>> available everywhere without having to add a header. Hence, the best place >>> to include trace_printk.h, is in kernel.h. >>> >>> I'm thinking that my proposed config option is the best solution now. For >>> those that do not care about debugging the kernel, you enable the >>> "HIDE_TRACE_PRINTK" config so that your builds will be "quicker". But for >>> everyone else, it will not slow down their workflow when they need to debug >>> code. >> >> 100% agree. We do have people running custom configs for faster builds, so this >> hide thing could be enabled there assuming those don't care about debug. >> >> In other words, "If it aint broke, don't fix it". > > But if I understand correctly, it would save 2% build time. That means 12 > secondes on a 10 minutes build. Is it really worth it ? > 99% of my kernel builds are usually 90 seconds. I throw a lot of cores at it and with ccache. I care more about trace_printk not being available than saving 2%. But YMMV. I am sure there are people who care a lot about build time, but for me it has not (yet) been a problem. - Joel
On Mon, 5 Jan 2026 14:33:35 -0500 Joel Fernandes <joelagnelf@nvidia.com> wrote: > >>> I'm thinking that my proposed config option is the best solution now. For > >>> those that do not care about debugging the kernel, you enable the > >>> "HIDE_TRACE_PRINTK" config so that your builds will be "quicker". But for > >>> everyone else, it will not slow down their workflow when they need to debug > >>> code. > >> > >> 100% agree. We do have people running custom configs for faster builds, so this > >> hide thing could be enabled there assuming those don't care about debug. > >> > >> In other words, "If it aint broke, don't fix it". > > > > But if I understand correctly, it would save 2% build time. That means 12 > > secondes on a 10 minutes build. Is it really worth it ? > > > 99% of my kernel builds are usually 90 seconds. I throw a lot of cores at it and > with ccache. I care more about trace_printk not being available than saving 2%. > But YMMV. I am sure there are people who care a lot about build time, but for me > it has not (yet) been a problem. I can see Linus enabling this. I don't think he uses trace_printk() to debug the kernel, so improving his build times may be useful. -- Steve
On 1/5/2026 3:04 PM, Steven Rostedt wrote: > On Mon, 5 Jan 2026 14:33:35 -0500 > Joel Fernandes <joelagnelf@nvidia.com> wrote: > >>>>> I'm thinking that my proposed config option is the best solution now. For >>>>> those that do not care about debugging the kernel, you enable the >>>>> "HIDE_TRACE_PRINTK" config so that your builds will be "quicker". But for >>>>> everyone else, it will not slow down their workflow when they need to debug >>>>> code. >>>> >>>> 100% agree. We do have people running custom configs for faster builds, so this >>>> hide thing could be enabled there assuming those don't care about debug. >>>> >>>> In other words, "If it aint broke, don't fix it". >>> >>> But if I understand correctly, it would save 2% build time. That means 12 >>> secondes on a 10 minutes build. Is it really worth it ? >>> >> 99% of my kernel builds are usually 90 seconds. I throw a lot of cores at it and >> with ccache. I care more about trace_printk not being available than saving 2%. >> But YMMV. I am sure there are people who care a lot about build time, but for me >> it has not (yet) been a problem. > > I can see Linus enabling this. I don't think he uses trace_printk() to > debug the kernel, so improving his build times may be useful. Sounds good to me. Making it an option sounds okay to me. Thanks.
On Sat, Jan 03, 2026 at 02:57:58PM +0200, Andy Shevchenko wrote:
> On Fri, Jan 02, 2026 at 07:50:59PM -0500, Joel Fernandes wrote:
> > On Mon, Dec 29, 2025 at 11:17:48AM -0500, Steven Rostedt wrote:
>
> ...
>
> > I use trace_printk() all the time for kernel, particularly RCU development.
> > One of the key usecases I have is dumping traces on panic (with panic on warn
> > and stop tracing on warn enabled). This is extremely useful since I can add
> > custom tracing and dump traces when rare conditions occur. I fixed several
> > bugs with this technique.
> >
> > I also recommend keeping it convenient to use.
>
> Okay, you know C, please share your opinion what header is the best to hold the
> trace_printk.h to be included.
What if we include it on Makefile level, similarly to how W=1 works?
make D=1 // trace_printk() is available
make D=0 // trace_printk() is not available
make // trace_printk() is not available
Where D stands for debugging.
D=1 may be a default setting if you prefer, but the most important is
that every compilation unit will have an access to debugging without
polluting core headers.
On Sat, 03 Jan 2026, Yury Norov <yury.norov@gmail.com> wrote: > On Sat, Jan 03, 2026 at 02:57:58PM +0200, Andy Shevchenko wrote: >> On Fri, Jan 02, 2026 at 07:50:59PM -0500, Joel Fernandes wrote: >> > On Mon, Dec 29, 2025 at 11:17:48AM -0500, Steven Rostedt wrote: >> >> ... >> >> > I use trace_printk() all the time for kernel, particularly RCU development. >> > One of the key usecases I have is dumping traces on panic (with panic on warn >> > and stop tracing on warn enabled). This is extremely useful since I can add >> > custom tracing and dump traces when rare conditions occur. I fixed several >> > bugs with this technique. >> > >> > I also recommend keeping it convenient to use. >> >> Okay, you know C, please share your opinion what header is the best to hold the >> trace_printk.h to be included. > > What if we include it on Makefile level, similarly to how W=1 works? > > make D=1 // trace_printk() is available > make D=0 // trace_printk() is not available > make // trace_printk() is not available > > Where D stands for debugging. > > D=1 may be a default setting if you prefer, but the most important is > that every compilation unit will have an access to debugging without > polluting core headers. You do realize this means recompiling everything when adding D=1 for debugging? BR, Jani. -- Jani Nikula, Intel
On Mon, Jan 05, 2026 at 11:29:51AM +0200, Jani Nikula wrote:
> On Sat, 03 Jan 2026, Yury Norov <yury.norov@gmail.com> wrote:
> > On Sat, Jan 03, 2026 at 02:57:58PM +0200, Andy Shevchenko wrote:
> >> On Fri, Jan 02, 2026 at 07:50:59PM -0500, Joel Fernandes wrote:
> >> > On Mon, Dec 29, 2025 at 11:17:48AM -0500, Steven Rostedt wrote:
> >>
> >> ...
> >>
> >> > I use trace_printk() all the time for kernel, particularly RCU development.
> >> > One of the key usecases I have is dumping traces on panic (with panic on warn
> >> > and stop tracing on warn enabled). This is extremely useful since I can add
> >> > custom tracing and dump traces when rare conditions occur. I fixed several
> >> > bugs with this technique.
> >> >
> >> > I also recommend keeping it convenient to use.
> >>
> >> Okay, you know C, please share your opinion what header is the best to hold the
> >> trace_printk.h to be included.
> >
> > What if we include it on Makefile level, similarly to how W=1 works?
> >
> > make D=1 // trace_printk() is available
> > make D=0 // trace_printk() is not available
> > make // trace_printk() is not available
> >
> > Where D stands for debugging.
> >
> > D=1 may be a default setting if you prefer, but the most important is
> > that every compilation unit will have an access to debugging without
> > polluting core headers.
>
> You do realize this means recompiling everything when adding D=1 for
> debugging?
Yes sir I do.
It would be as simple (or hard) as building another arch:
make O=../build/linux-arm64
make O=../build/linux-x86_64
make D=1 W=1 O=../build/linux-x86_64-dev
If you're both developer and CI engineer in your company, you're likely
already doing something like that. If you're CI-only, there're no
changes for you. If you're a developer - yeah, you'd have to learn a
new flag.
The real problem of course is the status inflation. The fact that
defconfig enables CONFIG_EXPERT and CONFIG_DEBUG_KERNEL implies that
every random person who is able to do:
git clone && make && sudo make install
now assumed an expert kernel user and active developer. It is not
correct, and it leads to bloating kernel with dev-only features.
What we discuss here is a new marker for those real experts and
developers, I think. (In an hope that it will inflate not very fast.)
Thanks,
Yury
On Mon, 05 Jan 2026, Yury Norov <yury.norov@gmail.com> wrote: > On Mon, Jan 05, 2026 at 11:29:51AM +0200, Jani Nikula wrote: >> On Sat, 03 Jan 2026, Yury Norov <yury.norov@gmail.com> wrote: >> > On Sat, Jan 03, 2026 at 02:57:58PM +0200, Andy Shevchenko wrote: >> >> On Fri, Jan 02, 2026 at 07:50:59PM -0500, Joel Fernandes wrote: >> >> > On Mon, Dec 29, 2025 at 11:17:48AM -0500, Steven Rostedt wrote: >> >> >> >> ... >> >> >> >> > I use trace_printk() all the time for kernel, particularly RCU development. >> >> > One of the key usecases I have is dumping traces on panic (with panic on warn >> >> > and stop tracing on warn enabled). This is extremely useful since I can add >> >> > custom tracing and dump traces when rare conditions occur. I fixed several >> >> > bugs with this technique. >> >> > >> >> > I also recommend keeping it convenient to use. >> >> >> >> Okay, you know C, please share your opinion what header is the best to hold the >> >> trace_printk.h to be included. >> > >> > What if we include it on Makefile level, similarly to how W=1 works? >> > >> > make D=1 // trace_printk() is available >> > make D=0 // trace_printk() is not available >> > make // trace_printk() is not available >> > >> > Where D stands for debugging. >> > >> > D=1 may be a default setting if you prefer, but the most important is >> > that every compilation unit will have an access to debugging without >> > polluting core headers. >> >> You do realize this means recompiling everything when adding D=1 for >> debugging? > > Yes sir I do. > > It would be as simple (or hard) as building another arch: > > make O=../build/linux-arm64 > make O=../build/linux-x86_64 > make D=1 W=1 O=../build/linux-x86_64-dev > > If you're both developer and CI engineer in your company, you're likely > already doing something like that. If you're CI-only, there're no > changes for you. If you're a developer - yeah, you'd have to learn a > new flag. Learn a new flag? What I'm saying is, if you're doing regular builds as a developer, and *then* realize you need trace_printk(), doing your suggested 'make D=1' rebuilds *everything*. Not exactly something you want in the middle of your development flow. I'd *rather* manually add that #include where needed, and rebuild just those files. I don't even feel very strongly about the whole thing, other than the D=1 being the worst suggestion so far in the thread. BR, Jani. > > The real problem of course is the status inflation. The fact that > defconfig enables CONFIG_EXPERT and CONFIG_DEBUG_KERNEL implies that > every random person who is able to do: > > git clone && make && sudo make install > > now assumed an expert kernel user and active developer. It is not > correct, and it leads to bloating kernel with dev-only features. > > What we discuss here is a new marker for those real experts and > developers, I think. (In an hope that it will inflate not very fast.) > > Thanks, > Yury -- Jani Nikula, Intel
On Mon, 5 Jan 2026 11:36:11 -0500
Yury Norov <yury.norov@gmail.com> wrote:
> > You do realize this means recompiling everything when adding D=1 for
> > debugging?
>
> Yes sir I do.
>
> It would be as simple (or hard) as building another arch:
>
> make O=../build/linux-arm64
> make O=../build/linux-x86_64
> make D=1 W=1 O=../build/linux-x86_64-dev
>
> If you're both developer and CI engineer in your company, you're likely
> already doing something like that. If you're CI-only, there're no
> changes for you. If you're a developer - yeah, you'd have to learn a
> new flag.
I'm saying this right now.
Hard-nacked-by: Steven Rostedt <rostedt@goodmis.org>
Why do you want to burden developers?
>
> The real problem of course is the status inflation. The fact that
> defconfig enables CONFIG_EXPERT and CONFIG_DEBUG_KERNEL implies that
> every random person who is able to do:
>
> git clone && make && sudo make install
>
> now assumed an expert kernel user and active developer. It is not
> correct, and it leads to bloating kernel with dev-only features.
>
> What we discuss here is a new marker for those real experts and
> developers, I think. (In an hope that it will inflate not very fast.)
This is a generic feature that helps all developers. The ones spending the
most time in maintaining the kernel.
Add the config I mentioned:
config HIDE_TRACE_PRINTK
depends on TRACING
help
trace_printk() is an extremely powerful utility to debug and develop
kernel code. It is defined in kernel.h so that it can be easily accessed
during development or having to debug existing code.
But trace_printk() is not to be included in the final result, and having
it in kernel.h during normal builds where the builder has no plans of
debugging the kernel causes wasted cycles and time in compiling the kernel.
By saying yes here, the include of trace_printk() macros will be hidden
from kernel.h and help speed up the compile.
If you do not plan on debugging this kernel, say Y
It is default 'n' as the normal person building their own kernel likely
wants to debug it. Once you set this to 'y' then you get your "fast" builds.
Then in kernel.h have:
#ifndef CONFIG_HIDE_TRACE_PRINTK
# include <linux/trace_printk.h>
#endif
-- Steve
On 2025-12-29 11:17, Steven Rostedt wrote: > On Sun, 28 Dec 2025 13:31:50 -0800 > Andrew Morton <akpm@linux-foundation.org> 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
On Mon, Dec 29, 2025 at 05:25:08PM -0500, Mathieu Desnoyers wrote: ... > 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. "by default" where exactly? The problem is that kernel.h is a total mess and it's included in a lot of mysterious ways (indirectly), and in C you _must_ include a header anyway for a custom API, just define *which* one. 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? -- With Best Regards, Andy Shevchenko
On 2025-12-30 03:55, Andy Shevchenko wrote: > On Mon, Dec 29, 2025 at 05:25:08PM -0500, Mathieu Desnoyers wrote: > > ... > >> 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. > > "by default" where exactly? The problem is that kernel.h is a total mess and > it's included in a lot of mysterious ways (indirectly), 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. :) > > 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? 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. Thanks, Mathieu -- Mathieu Desnoyers EfficiOS Inc. https://www.efficios.com
On Tue, Dec 30, 2025 at 09:21:00AM -0500, Mathieu Desnoyers wrote: > On 2025-12-30 03:55, Andy Shevchenko wrote: > > On Mon, Dec 29, 2025 at 05:25:08PM -0500, Mathieu Desnoyers wrote: > > > > ... > > > > > 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. > > > But please make sure the default stays as it is today: > > > include the trace printk header by default. > > > > "by default" where exactly? Seemingly nowhere. > > The problem is that kernel.h is a total mess and > > it's included in a lot of mysterious ways (indirectly), Yes! > > 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. :) > > > > > 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
On Tue, 30 Dec 2025 11:18:37 -0500 Yury Norov <yury.norov@gmail.com> wrote: > On Tue, Dec 30, 2025 at 09:21:00AM -0500, Mathieu Desnoyers wrote: > > On 2025-12-30 03:55, Andy Shevchenko wrote: > > > On Mon, Dec 29, 2025 at 05:25:08PM -0500, Mathieu Desnoyers wrote: > > > > > > ... > > > > > > > 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. Tracing is used in production all the time. So I think we can have a new config just for trace_printk(). I was actually thinking of adding a CONFIG_HIDE_TRACE_PRINTK, with the description of: trace_printk() is an extremely powerful utility to debug and develop kernel code. It is defined in kernel.h so that it can be easily accessed during development or having to debug existing code. But trace_printk() is not to be included in the final result, and having it in kernel.h during normal builds where the builder has no plans of debugging the kernel causes wasted cycles and time in compiling the kernel. By saying yes here, the include of trace_printk() macros will be hidden from kernel.h and help speed up the compile. If you do not plan on debugging this kernel, say Y And then have in kernel.h: #ifndef CONFIG_HIDE_TRACE_PRINTK # include <linux/trace_printk.h> #endif This also means it gets set for allyesconfig builds, which I doubt anyone wants to debug anyway. > > > > > But please make sure the default stays as it is today: > > > > include the trace printk header by default. > > > > > > "by default" where exactly? > > Seemingly nowhere. > > > > The problem is that kernel.h is a total mess and > > > it's included in a lot of mysterious ways (indirectly), > > Yes! > > > > 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. :) > > > > > > > > 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?) I actually agree with you here. I don't think adding trace_printk.h into printk.h is appropriate. I only said that anywhere you can add a printk() for debugging, you should also be able to add trace_printk(). I believe kernel.h is the appropriate place for both. > > 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? Absolutely not. Tracing is used to debug production kernels, and things like live kernel patching also depend on it, not to mention BPF. > > 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... Looks fine to me. -- Steve
On Mon, Dec 29, 2025 at 11:17:48AM -0500, Steven Rostedt wrote:
> But sure, if you want to save the few minutes that is added to "make
> allyesconfig"
Nah, it is
"Removing trace_printk.h saves 1.5-2% of compilation time on my
Ubuntu-derived x86_64/localyesconfig"
which is:
localyesconfig - Update current config converting local mods to core
and which makes me wonder - who does that?
What are we actually optimizing here?
And 1-2% at that.
I don't see how this outweighs the goodness of using trace_printk()
everywhere.
So that's a NO on that patch from me too.
Thx.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
On Mon Dec 29, 2025 at 5:17 PM CET, Steven Rostedt wrote: > It will waste a lot of kernel developers time. Go to conferences and talk > with developers. trace_printk() is now one of the most common ways to debug > your code. Having to add "#include <linux/trace_printk.h>" in every file > that you use trace_printk() (and after your build fails because you forgot > to include that file **WILL** slow down kernel debugging for hundreds of > developers! It *is* used more than printk() for debugging today. Because > it's fast and can be used in any context (NMI, interrupt handlers, etc). I strongly agree with this. I heavly use trace_printk() for debugging for a long time and have recommended it to dozens of people that all have been very thankful for it -- especially when it comes to debugging race conditions on a tough timing, where a normal printk() simply "fixes" the race. Having to include additional headers would be very painful, especially when debugging large code bases with lots of files. For instance, one of the components I maintain is the nouveau driver with 773 C files and 1390 files overall. I suppose it would be fair to argue that such codebases usually have their own common header files that could be reused, but even in that case, I’d consider the ergonomic cost too high. - Danilo
On Fri, Dec 26, 2025 at 11:58:48AM -0500, Steven Rostedt wrote: > On Thu, 25 Dec 2025 12:09:29 -0500 > "Yury Norov (NVIDIA)" <yury.norov@gmail.com> wrote: > > > The trace_printk.h header is debugging-only by nature, but now it's > > included by almost every compilation unit via kernel.h. > > > > Removing trace_printk.h saves 1.5-2% of compilation time on my > > Ubuntu-derived x86_64/localyesconfig. > > > > There's ~30 files in the codebase, requiring trace_printk.h for > > non-debugging reasons: mostly to disable tracing on panic or under > > similar conditions. Include the header for those explicitly. > > > > This implicitly decouples linux/kernel.h and linux/instruction_pointer.h > > as well, because it has been isolated to trace_printk.h early in the > > series. > > > > Signed-off-by: Yury Norov (NVIDIA) <yury.norov@gmail.com> > > I'm still against this patch. It means every time someone adds > trace_printk() they need to add the header for it. > > trace_printk() should be as available to the kernel as printk() is. If > there's a place that one can add printk() without adding a header, then > they should be able to add trace_printk() to that same location without > adding any header. If that's not the case, then I'm adding an official > > Nacked-by: Steven Rostedt <rostedt@goodmis.org> > > I'm fine for trying other ways to speed up the compilation, but removing > full access to trace_printk() isn't one of them. I interpreted this as if the header inclusion should be moved from kernel.h to printk.h as a compromise that satisfies all (?) stakeholders. Is it possible approach? -- With Best Regards, Andy Shevchenko
On Sat, 27 Dec 2025 16:45:47 +0200 Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote: > > I'm fine for trying other ways to speed up the compilation, but removing > > full access to trace_printk() isn't one of them. > > I interpreted this as if the header inclusion should be moved from kernel.h > to printk.h as a compromise that satisfies all (?) stakeholders. Is it possible > approach? I'm fine with putting the include of trace_printk.h into printk.h. If you remove printk.h from kernel.h I would expect a lot more people to complain about it. Including Linus himself. -- Steve
On Sat, Dec 27, 2025 at 10:57:01AM -0500, Steven Rostedt wrote: > On Sat, 27 Dec 2025 16:45:47 +0200 > Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote: > > > > I'm fine for trying other ways to speed up the compilation, but removing > > > full access to trace_printk() isn't one of them. OK, then let's keep trace_printk() available for kernel.h users. Andrew, can you take the first 6 patches of the series, if no other objections? > > I interpreted this as if the header inclusion should be moved from kernel.h > > to printk.h as a compromise that satisfies all (?) stakeholders. Is it possible > > approach? > > I'm fine with putting the include of trace_printk.h into printk.h. If > you remove printk.h from kernel.h I would expect a lot more people to > complain about it. Including Linus himself. The difference is that printk() is not a debugging tool. It is used widely to report errors and info messages. Normally, I want to cleanup all debugging code from my module after finishing development. If trace_printk.h will be a part of printk.h, there's always a chance to miss trace_printk() somewhere. I'd prefer to keep them separate. Thanks, Yury
On Sat, 27 Dec 2025 14:35:52 -0500 Yury Norov <yury.norov@gmail.com> wrote: > The difference is that printk() is not a debugging tool. Several developers will disagree with you. In fact, Linus has said he uses printk() as his preferred debugging tool! The only reason to have printk.h in kernel.h is because it *is* used for debugging! If it wasn't used for debugging, then you could simply add printk.h for those places that needed to use printk(). But because it is one of the most common debugging tools, having it in kernel.h is useful, as you don't want to have to add #include <printk.h> every time you added a printk() for debugging purposes (same is true for trace_printk()). Yes, it is also used for information. But if that's all it was used for, then it wouldn't need to be in kernel.h. It could be a normal header file that anything that needed to print information would have to include. -- Steve
© 2016 - 2026 Red Hat, Inc.