tracing: Move trace_printk.h out of kernel.h

From: Steven Rostedt <[email protected]>

In order to remove the include to trace_printk.h from kernel.h the tracing control prototypes need to be moved back into kernel.h. That's because

they are used in other common header files like rcu.h. There's no point in removing trace_printk.h from kernel.h if it just gets added back to other common headers.

Prototypes are very cheap for the compiler and should not be an issue.

Signed-off-by Steven Rostedt <[email protected]>

---
 include/linux/kernel.h       | 18 ++++++++++++++++++
 include/linux/trace_printk.h | 17 -----------------
 2 files changed, 18 insertions(+), 17 deletions(-)

include/linux/kernel.h +18 -0

index e5570a16cbb1..c3c68128827c 100644
@@ -194,4 +194,22 @@ extern enum system_states system_state;
 # define REBUILD_DUE_TO_DYNAMIC_FTRACE
 #endif
 
+#ifdef CONFIG_TRACING
+void tracing_on(void);
+void tracing_off(void);
+int tracing_is_on(void);
+void tracing_snapshot(void);
+void tracing_snapshot_alloc(void);
+void tracing_start(void);
+void tracing_stop(void);
+#else
+static inline void tracing_start(void) { }
+static inline void tracing_stop(void) { }
+static inline void tracing_on(void) { }
+static inline void tracing_off(void) { }
+static inline int tracing_is_on(void) { return 0; }
+static inline void tracing_snapshot(void) { }
+static inline void tracing_snapshot_alloc(void) { }
+#endif
+
 #endif

include/linux/trace_printk.h +0 -17

index 3d54f440dccf..879fed0805fd 100644
@@ -35,15 +35,6 @@ enum ftrace_dump_mode {
 };
 
 #ifdef CONFIG_TRACING
-void tracing_on(void);
-void tracing_off(void);
-int tracing_is_on(void);
-void tracing_snapshot(void);
-void tracing_snapshot_alloc(void);
-
-extern void tracing_start(void);
-extern void tracing_stop(void);
-
 static inline __printf(1, 2)
 void ____trace_printk_check_format(const char *fmt, ...)
 {

@@ -176,16 +167,8 @@ __ftrace_vprintk(unsigned long ip, const char *fmt, va_list ap);
 
 extern void ftrace_dump(enum ftrace_dump_mode oops_dump_mode);
 #else
-static inline void tracing_start(void) { }
-static inline void tracing_stop(void) { }
 static inline void trace_dump_stack(int skip) { }
 
-static inline void tracing_on(void) { }
-static inline void tracing_off(void) { }
-static inline int tracing_is_on(void) { return 0; }
-static inline void tracing_snapshot(void) { }
-static inline void tracing_snapshot_alloc(void) { }
-
 static inline __printf(1, 2)
 int trace_printk(const char *fmt, ...)
 {

Signature · 1 line

2.53.0

Quoted 4 lines · Steven Rostedt

From: Steven Rostedt <[email protected]>

In order to remove the include to trace_printk.h from kernel.h the tracing control prototypes need to be moved back into kernel.h. That's because

Please don't. Instead, you can split them out to trace_control.h, and include where needed. I actually have a prototype for it, FYI:

https://github.com/norov/linux/tree/trace_pritk3

Quoted 5 lines

they are used in other common header files like rcu.h. There's no point in removing trace_printk.h from kernel.h if it just gets added back to other common headers.

Prototypes are very cheap for the compiler and should not be an issue.

It's not about cost, it's about mess. kernel.h is included everywhere. Is that API needed everywhere? No, it's needed in literally 10 files. So, no place in kernel.h.

Quoted 3 lines

2.53.0

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.

Quoted 6 lines · 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.

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

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.

Quoted 10 lines · Steven Rostedt

Quoted 6 lines · 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.

Quoted 2 lines

Bah, I only tested with the config option enabled, and missed some dependencies with it disabled.

Yes you did.

Quoted 2 lines

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

No, it shouldn't.

Quoted 4 lines

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

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.

Quoted 6 lines · Steven Rostedt

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.

IOW, you make it worse just because.

With the header being separate I add the three trace_printk()s and the include to the source file I'm investigating. The recompile will build exactly this source file.

Having to enable the config knob will result in a full kernel rebuild for no value.

Seriously?

Thanks,

tglx

Quoted 6 lines · Steven Rostedt

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.

IOW, you make it worse just because.

With the header being separate I add the three trace_printk()s and the include to the source file I'm investigating. The recompile will build exactly this source file.

Having to enable the config knob will result in a full kernel rebuild for no value.

Seriously?

Thanks,

tglx

Indeed...
Isn't trace_printk() just an extern?
Having it defined somewhere isn't going to make any difference to build times.

There's been complaints about trace_printk() being defined in kernel.h as it can increase the compilation time. As it is only used by some developers for debugging purposes, it should not be in kernel.h causing lots of wasted CPU cycles for those that do not ever care about it.

Instead, add a CONFIG_TRACE_PRINTK_DEBUGGING option that developers that do use it can set and not have to always remember to add #include <linux/trace_printk.h> to the files they add trace_printk() while debugging. It also means that those that do not have that config set will not have to worry about wasted CPU cycles as it is only include in the CFLAGS when the option is set, and its completely ignored otherwise.

Steven Rostedt (2):
tracing: Move non-trace_printk prototypes back to kernel.h
tracing: Add CONFIG_TRACE_PRINTK_DEBUGGING to clean up kernel.h

----

  .../driver_development_debugging_guide.rst         |  2 +-
  Makefile                                           |  5 +++++
  arch/powerpc/kvm/book3s_xics.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                  |  4 ++++
  drivers/infiniband/hw/hfi1/trace_dbg.h             |  1 +
  drivers/usb/early/xhci-dbc.c                       |  1 +
  fs/ext4/inline.c                                   |  1 +
  include/linux/kernel.h                             | 19 ++++++++++++++++++-
  include/linux/sunrpc/debug.h                       |  1 +
  include/linux/trace_printk.h                       | 22 +++-------------------
  kernel/trace/Kconfig                               | 10 ++++++++++
  kernel/trace/ring_buffer_benchmark.c               |  1 +
  kernel/trace/trace.h                               |  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               |  2 +-
  samples/ftrace/ftrace-direct-too.c                 |  2 +-
  samples/ftrace/ftrace-direct.c                     |  2 +-
  21 files changed, 56 insertions(+), 24 deletions(-)

Quoted 4 lines

There's been complaints about trace_printk() being defined in kernel.h as it can increase the compilation time. As it is only used by some developers for debugging purposes, it should not be in kernel.h causing lots of wasted CPU cycles for those that do not ever care about it.

Do we have a measurement of the increased compilation time ?

Quoted 6 lines · On Mon, 22 Jun 2026 10:05:13 +0200 "Christophe Leroy (CS GROUP)"…

Quoted 4 lines

There's been complaints about trace_printk() being defined in kernel.h as it can increase the compilation time. As it is only used by some developers for debugging purposes, it should not be in kernel.h causing lots of wasted CPU cycles for those that do not ever care about it.

Do we have a measurement of the increased compilation time ?

I believe Yury does.

There's been complaints about trace_printk() being defined in kernel.h as it can increase the compilation time. As it is only used by some developers for debugging purposes, it should not be in kernel.h causing lots of wasted CPU cycles for those that do not ever care about it.

Instead, add a CONFIG_TRACE_PRINTK_DEBUGGING option that developers that do use it can set and not have to always remember to add #include <linux/trace_printk.h> to the files they add trace_printk() while debugging. It also means that those that do not have that config set will not have to worry about wasted CPU cycles as it is only include in the CFLAGS when the option is set, and its completely ignored otherwise.

Did you forget your C 101 class? If you use a function, you gotta include the relevant header.

Quoted 11 lines · Steven Rostedt

There's been complaints about trace_printk() being defined in kernel.h as it can increase the compilation time. As it is only used by some developers for debugging purposes, it should not be in kernel.h causing lots of wasted CPU cycles for those that do not ever care about it.

Instead, add a CONFIG_TRACE_PRINTK_DEBUGGING option that developers that do use it can set and not have to always remember to add #include <linux/trace_printk.h> to the files they add trace_printk() while debugging. It also means that those that do not have that config set will not have to worry about wasted CPU cycles as it is only include in the CFLAGS when the option is set, and its completely ignored otherwise.

Did you forget your C 101 class? If you use a function, you gotta include the relevant header.

You don't see userspace saying: 'Hey, you know what, perhaps we should add stdio.h to every other header, just in case someone wants to printf()' either.

I really don't understand your argument. Yes, maybe someone will forget and then either their editor (if they have a halfway modern setup with LSP enabled) or their build will complain, but so what? This is all trivial stuff, surely we have more pressing matters to concern outselves with?

Quoted 2 lines

Did you forget your C 101 class? If you use a function, you gotta include the relevant header.

Also item #1 in Documentation/process/submit-checklist.rst.