Tracing is a half of the kernel.h in terms of LOCs, although it's a
self-consistent part. Move it to a separate header.
This is a pure move, except for removing a few 'extern's.
Signed-off-by: Yury Norov (NVIDIA) <yury.norov@gmail.com>
---
MAINTAINERS | 1 +
include/linux/kernel.h | 195 +-------------------------------------
include/linux/tracing.h | 203 ++++++++++++++++++++++++++++++++++++++++
3 files changed, 205 insertions(+), 194 deletions(-)
create mode 100644 include/linux/tracing.h
diff --git a/MAINTAINERS b/MAINTAINERS
index be6a4217caa5..706bbb5da263 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -26071,6 +26071,7 @@ T: git git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace.git
F: Documentation/trace/*
F: fs/tracefs/
F: include/linux/trace*.h
+F: include/linux/tracing.h
F: include/trace/
F: kernel/trace/
F: kernel/tracepoint.c
diff --git a/include/linux/kernel.h b/include/linux/kernel.h
index 5b879bfea948..265c0d31f369 100644
--- a/include/linux/kernel.h
+++ b/include/linux/kernel.h
@@ -27,6 +27,7 @@
#include <linux/math.h>
#include <linux/minmax.h>
#include <linux/typecheck.h>
+#include <linux/tracing.h>
#include <linux/panic.h>
#include <linux/printk.h>
#include <linux/build_bug.h>
@@ -190,200 +191,6 @@ enum system_states {
};
extern enum system_states system_state;
-/*
- * General tracing related utility functions - trace_printk(),
- * tracing_on/tracing_off and tracing_start()/tracing_stop
- *
- * Use tracing_on/tracing_off when you want to quickly turn on or off
- * tracing. It simply enables or disables the recording of the trace events.
- * This also corresponds to the user space /sys/kernel/tracing/tracing_on
- * file, which gives a means for the kernel and userspace to interact.
- * Place a tracing_off() in the kernel where you want tracing to end.
- * From user space, examine the trace, and then echo 1 > tracing_on
- * to continue tracing.
- *
- * tracing_stop/tracing_start has slightly more overhead. It is used
- * by things like suspend to ram where disabling the recording of the
- * trace is not enough, but tracing must actually stop because things
- * like calling smp_processor_id() may crash the system.
- *
- * Most likely, you want to use tracing_on/tracing_off.
- */
-
-enum ftrace_dump_mode {
- DUMP_NONE,
- DUMP_ALL,
- DUMP_ORIG,
- DUMP_PARAM,
-};
-
-#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, ...)
-{
-}
-#define __trace_printk_check_format(fmt, args...) \
-do { \
- if (0) \
- ____trace_printk_check_format(fmt, ##args); \
-} while (0)
-
-/**
- * trace_printk - printf formatting in the ftrace buffer
- * @fmt: the printf format for printing
- *
- * Note: __trace_printk is an internal function for trace_printk() and
- * the @ip is passed in via the trace_printk() macro.
- *
- * This function allows a kernel developer to debug fast path sections
- * that printk is not appropriate for. By scattering in various
- * printk like tracing in the code, a developer can quickly see
- * where problems are occurring.
- *
- * This is intended as a debugging tool for the developer only.
- * Please refrain from leaving trace_printks scattered around in
- * your code. (Extra memory is used for special buffers that are
- * allocated when trace_printk() is used.)
- *
- * A little optimization trick is done here. If there's only one
- * argument, there's no need to scan the string for printf formats.
- * The trace_puts() will suffice. But how can we take advantage of
- * using trace_puts() when trace_printk() has only one argument?
- * By stringifying the args and checking the size we can tell
- * whether or not there are args. __stringify((__VA_ARGS__)) will
- * turn into "()\0" with a size of 3 when there are no args, anything
- * else will be bigger. All we need to do is define a string to this,
- * and then take its size and compare to 3. If it's bigger, use
- * do_trace_printk() otherwise, optimize it to trace_puts(). Then just
- * let gcc optimize the rest.
- */
-
-#define trace_printk(fmt, ...) \
-do { \
- char _______STR[] = __stringify((__VA_ARGS__)); \
- if (sizeof(_______STR) > 3) \
- do_trace_printk(fmt, ##__VA_ARGS__); \
- else \
- trace_puts(fmt); \
-} while (0)
-
-#define do_trace_printk(fmt, args...) \
-do { \
- static const char *trace_printk_fmt __used \
- __section("__trace_printk_fmt") = \
- __builtin_constant_p(fmt) ? fmt : NULL; \
- \
- __trace_printk_check_format(fmt, ##args); \
- \
- if (__builtin_constant_p(fmt)) \
- __trace_bprintk(_THIS_IP_, trace_printk_fmt, ##args); \
- else \
- __trace_printk(_THIS_IP_, fmt, ##args); \
-} while (0)
-
-extern __printf(2, 3)
-int __trace_bprintk(unsigned long ip, const char *fmt, ...);
-
-extern __printf(2, 3)
-int __trace_printk(unsigned long ip, const char *fmt, ...);
-
-/**
- * trace_puts - write a string into the ftrace buffer
- * @str: the string to record
- *
- * Note: __trace_bputs is an internal function for trace_puts and
- * the @ip is passed in via the trace_puts macro.
- *
- * This is similar to trace_printk() but is made for those really fast
- * paths that a developer wants the least amount of "Heisenbug" effects,
- * where the processing of the print format is still too much.
- *
- * This function allows a kernel developer to debug fast path sections
- * that printk is not appropriate for. By scattering in various
- * printk like tracing in the code, a developer can quickly see
- * where problems are occurring.
- *
- * This is intended as a debugging tool for the developer only.
- * Please refrain from leaving trace_puts scattered around in
- * your code. (Extra memory is used for special buffers that are
- * allocated when trace_puts() is used.)
- *
- * Returns: 0 if nothing was written, positive # if string was.
- * (1 when __trace_bputs is used, strlen(str) when __trace_puts is used)
- */
-
-#define trace_puts(str) ({ \
- static const char *trace_printk_fmt __used \
- __section("__trace_printk_fmt") = \
- __builtin_constant_p(str) ? str : NULL; \
- \
- if (__builtin_constant_p(str)) \
- __trace_bputs(_THIS_IP_, trace_printk_fmt); \
- else \
- __trace_puts(_THIS_IP_, str, strlen(str)); \
-})
-extern int __trace_bputs(unsigned long ip, const char *str);
-extern int __trace_puts(unsigned long ip, const char *str, int size);
-
-extern void trace_dump_stack(int skip);
-
-/*
- * The double __builtin_constant_p is because gcc will give us an error
- * if we try to allocate the static variable to fmt if it is not a
- * constant. Even with the outer if statement.
- */
-#define ftrace_vprintk(fmt, vargs) \
-do { \
- if (__builtin_constant_p(fmt)) { \
- static const char *trace_printk_fmt __used \
- __section("__trace_printk_fmt") = \
- __builtin_constant_p(fmt) ? fmt : NULL; \
- \
- __ftrace_vbprintk(_THIS_IP_, trace_printk_fmt, vargs); \
- } else \
- __ftrace_vprintk(_THIS_IP_, fmt, vargs); \
-} while (0)
-
-extern __printf(2, 0) int
-__ftrace_vbprintk(unsigned long ip, const char *fmt, va_list ap);
-
-extern __printf(2, 0) int
-__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, ...)
-{
- return 0;
-}
-static __printf(1, 0) inline int
-ftrace_vprintk(const char *fmt, va_list ap)
-{
- return 0;
-}
-static inline void ftrace_dump(enum ftrace_dump_mode oops_dump_mode) { }
-#endif /* CONFIG_TRACING */
-
/* Rebuild everything on CONFIG_DYNAMIC_FTRACE */
#ifdef CONFIG_DYNAMIC_FTRACE
# define REBUILD_DUE_TO_DYNAMIC_FTRACE
diff --git a/include/linux/tracing.h b/include/linux/tracing.h
new file mode 100644
index 000000000000..1989e6328c59
--- /dev/null
+++ b/include/linux/tracing.h
@@ -0,0 +1,203 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef _LINUX_TRACING_H
+#define _LINUX_TRACING_H
+
+#include <linux/compiler_attributes.h>
+#include <linux/instruction_pointer.h>
+#include <linux/stringify.h>
+
+/*
+ * General tracing related utility functions - trace_printk(),
+ * tracing_on/tracing_off and tracing_start()/tracing_stop
+ *
+ * Use tracing_on/tracing_off when you want to quickly turn on or off
+ * tracing. It simply enables or disables the recording of the trace events.
+ * This also corresponds to the user space /sys/kernel/tracing/tracing_on
+ * file, which gives a means for the kernel and userspace to interact.
+ * Place a tracing_off() in the kernel where you want tracing to end.
+ * From user space, examine the trace, and then echo 1 > tracing_on
+ * to continue tracing.
+ *
+ * tracing_stop/tracing_start has slightly more overhead. It is used
+ * by things like suspend to ram where disabling the recording of the
+ * trace is not enough, but tracing must actually stop because things
+ * like calling smp_processor_id() may crash the system.
+ *
+ * Most likely, you want to use tracing_on/tracing_off.
+ */
+
+enum ftrace_dump_mode {
+ DUMP_NONE,
+ DUMP_ALL,
+ DUMP_ORIG,
+ DUMP_PARAM,
+};
+
+#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);
+
+static inline __printf(1, 2)
+void ____trace_printk_check_format(const char *fmt, ...)
+{
+}
+#define __trace_printk_check_format(fmt, args...) \
+do { \
+ if (0) \
+ ____trace_printk_check_format(fmt, ##args); \
+} while (0)
+
+/**
+ * trace_printk - printf formatting in the ftrace buffer
+ * @fmt: the printf format for printing
+ *
+ * Note: __trace_printk is an internal function for trace_printk() and
+ * the @ip is passed in via the trace_printk() macro.
+ *
+ * This function allows a kernel developer to debug fast path sections
+ * that printk is not appropriate for. By scattering in various
+ * printk like tracing in the code, a developer can quickly see
+ * where problems are occurring.
+ *
+ * This is intended as a debugging tool for the developer only.
+ * Please refrain from leaving trace_printks scattered around in
+ * your code. (Extra memory is used for special buffers that are
+ * allocated when trace_printk() is used.)
+ *
+ * A little optimization trick is done here. If there's only one
+ * argument, there's no need to scan the string for printf formats.
+ * The trace_puts() will suffice. But how can we take advantage of
+ * using trace_puts() when trace_printk() has only one argument?
+ * By stringifying the args and checking the size we can tell
+ * whether or not there are args. __stringify((__VA_ARGS__)) will
+ * turn into "()\0" with a size of 3 when there are no args, anything
+ * else will be bigger. All we need to do is define a string to this,
+ * and then take its size and compare to 3. If it's bigger, use
+ * do_trace_printk() otherwise, optimize it to trace_puts(). Then just
+ * let gcc optimize the rest.
+ */
+
+#define trace_printk(fmt, ...) \
+do { \
+ char _______STR[] = __stringify((__VA_ARGS__)); \
+ if (sizeof(_______STR) > 3) \
+ do_trace_printk(fmt, ##__VA_ARGS__); \
+ else \
+ trace_puts(fmt); \
+} while (0)
+
+#define do_trace_printk(fmt, args...) \
+do { \
+ static const char *trace_printk_fmt __used \
+ __section("__trace_printk_fmt") = \
+ __builtin_constant_p(fmt) ? fmt : NULL; \
+ \
+ __trace_printk_check_format(fmt, ##args); \
+ \
+ if (__builtin_constant_p(fmt)) \
+ __trace_bprintk(_THIS_IP_, trace_printk_fmt, ##args); \
+ else \
+ __trace_printk(_THIS_IP_, fmt, ##args); \
+} while (0)
+
+__printf(2, 3)
+int __trace_bprintk(unsigned long ip, const char *fmt, ...);
+
+__printf(2, 3)
+int __trace_printk(unsigned long ip, const char *fmt, ...);
+
+/**
+ * trace_puts - write a string into the ftrace buffer
+ * @str: the string to record
+ *
+ * Note: __trace_bputs is an internal function for trace_puts and
+ * the @ip is passed in via the trace_puts macro.
+ *
+ * This is similar to trace_printk() but is made for those really fast
+ * paths that a developer wants the least amount of "Heisenbug" effects,
+ * where the processing of the print format is still too much.
+ *
+ * This function allows a kernel developer to debug fast path sections
+ * that printk is not appropriate for. By scattering in various
+ * printk like tracing in the code, a developer can quickly see
+ * where problems are occurring.
+ *
+ * This is intended as a debugging tool for the developer only.
+ * Please refrain from leaving trace_puts scattered around in
+ * your code. (Extra memory is used for special buffers that are
+ * allocated when trace_puts() is used.)
+ *
+ * Returns: 0 if nothing was written, positive # if string was.
+ * (1 when __trace_bputs is used, strlen(str) when __trace_puts is used)
+ */
+
+#define trace_puts(str) ({ \
+ static const char *trace_printk_fmt __used \
+ __section("__trace_printk_fmt") = \
+ __builtin_constant_p(str) ? str : NULL; \
+ \
+ if (__builtin_constant_p(str)) \
+ __trace_bputs(_THIS_IP_, trace_printk_fmt); \
+ else \
+ __trace_puts(_THIS_IP_, str, strlen(str)); \
+})
+int __trace_bputs(unsigned long ip, const char *str);
+int __trace_puts(unsigned long ip, const char *str, int size);
+
+void trace_dump_stack(int skip);
+
+/*
+ * The double __builtin_constant_p is because gcc will give us an error
+ * if we try to allocate the static variable to fmt if it is not a
+ * constant. Even with the outer if statement.
+ */
+#define ftrace_vprintk(fmt, vargs) \
+do { \
+ if (__builtin_constant_p(fmt)) { \
+ static const char *trace_printk_fmt __used \
+ __section("__trace_printk_fmt") = \
+ __builtin_constant_p(fmt) ? fmt : NULL; \
+ \
+ __ftrace_vbprintk(_THIS_IP_, trace_printk_fmt, vargs); \
+ } else \
+ __ftrace_vprintk(_THIS_IP_, fmt, vargs); \
+} while (0)
+
+__printf(2, 0) int
+__ftrace_vbprintk(unsigned long ip, const char *fmt, va_list ap);
+
+__printf(2, 0) int
+__ftrace_vprintk(unsigned long ip, const char *fmt, va_list ap);
+
+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, ...)
+{
+ return 0;
+}
+static __printf(1, 0) inline int
+ftrace_vprintk(const char *fmt, va_list ap)
+{
+ return 0;
+}
+static inline void ftrace_dump(enum ftrace_dump_mode oops_dump_mode) { }
+#endif /* CONFIG_TRACING */
+
+#endif
--
2.43.0On Sat, 29 Nov 2025 14:53:02 -0500 "Yury Norov (NVIDIA)" <yury.norov@gmail.com> wrote: > --- a/include/linux/kernel.h > +++ b/include/linux/kernel.h > @@ -27,6 +27,7 @@ > #include <linux/math.h> > #include <linux/minmax.h> > #include <linux/typecheck.h> > +#include <linux/tracing.h> > #include <linux/panic.h> > #include <linux/printk.h> > #include <linux/build_bug.h> I'm fine with this as long as it's available as much as printk is. Acked-by: Steven Rostedt <rostedt@goodmis.org> -- Steve
On Sat, Nov 29, 2025 at 02:53:02PM -0500, Yury Norov (NVIDIA) wrote: > Tracing is a half of the kernel.h in terms of LOCs, although it's a > self-consistent part. Move it to a separate header. > > This is a pure move, except for removing a few 'extern's. Yeah, I also have something similar (but half-baked) locally, the Q I wanted to ask is why a separate header? We have already some of tracing headers. Doesn't suit well? ... > --- a/include/linux/kernel.h > +++ b/include/linux/kernel.h > @@ -27,6 +27,7 @@ > #include <linux/math.h> > #include <linux/minmax.h> > #include <linux/typecheck.h> > +#include <linux/tracing.h> There is better place for t*.h, i.e. after static_call_types.h. Btw, have you tried to sort alphabetically the bulk in the kernel.h after your series. Does it still build? (Just wondering about state of affairs with the possible cyclic dependencies.) > #include <linux/panic.h> > #include <linux/printk.h> > #include <linux/build_bug.h> -- With Best Regards, Andy Shevchenko
On Sat, Nov 29, 2025 at 10:30:23PM +0200, Andy Shevchenko wrote: > On Sat, Nov 29, 2025 at 02:53:02PM -0500, Yury Norov (NVIDIA) wrote: > > Tracing is a half of the kernel.h in terms of LOCs, although it's a > > self-consistent part. Move it to a separate header. > > > > This is a pure move, except for removing a few 'extern's. > > Yeah, I also have something similar (but half-baked) locally, the Q I wanted to > ask is why a separate header? We have already some of tracing headers. Doesn't > suit well? Just as said in the commit message - this part is more or less self-consistent and debugging-oriented. If someone needs to just throw trace_printk() in their driver, they will not have to pull all the heavy tracing machinery. > ... > > > --- a/include/linux/kernel.h > > +++ b/include/linux/kernel.h > > @@ -27,6 +27,7 @@ > > #include <linux/math.h> > > #include <linux/minmax.h> > > #include <linux/typecheck.h> > > > +#include <linux/tracing.h> > > There is better place for t*.h, i.e. after static_call_types.h. They are poorly sorted for seemingly no good reason. I found the first t*.h and just put this header next to it. Don't think that placing it next to static_call_types.h is any better or worse. > Btw, have you tried to sort alphabetically the bulk in the kernel.h after > your series. Does it still build? (Just wondering about state of affairs > with the possible cyclic dependencies.) I didn't try. Sorting #include's is not the purpose of the series. Thanks, Yury
On Sun, Nov 30, 2025 at 01:16:19PM -0500, Yury Norov wrote: > On Sat, Nov 29, 2025 at 10:30:23PM +0200, Andy Shevchenko wrote: > > On Sat, Nov 29, 2025 at 02:53:02PM -0500, Yury Norov (NVIDIA) wrote: > > > Tracing is a half of the kernel.h in terms of LOCs, although it's a > > > self-consistent part. Move it to a separate header. > > > > > > This is a pure move, except for removing a few 'extern's. > > > > Yeah, I also have something similar (but half-baked) locally, the Q I wanted to > > ask is why a separate header? We have already some of tracing headers. Doesn't > > suit well? > > Just as said in the commit message - this part is more or less > self-consistent and debugging-oriented. If someone needs to just > throw trace_printk() in their driver, they will not have to pull > all the heavy tracing machinery. Please, add a summary of this to it. It will be much clearer and based on it I agree with your judgement. ... > > > --- a/include/linux/kernel.h > > > +++ b/include/linux/kernel.h > > > @@ -27,6 +27,7 @@ > > > #include <linux/math.h> > > > #include <linux/minmax.h> > > > #include <linux/typecheck.h> > > > > > +#include <linux/tracing.h> > > > > There is better place for t*.h, i.e. after static_call_types.h. > > They are poorly sorted for seemingly no good reason. I found the first > t*.h and just put this header next to it. Don't think that placing it > next to static_call_types.h is any better or worse. It's better, because the (sparsed) chain of the sorted one is longer. > > Btw, have you tried to sort alphabetically the bulk in the kernel.h after > > your series. Does it still build? (Just wondering about state of affairs > > with the possible cyclic dependencies.) > > I didn't try. Sorting #include's is not the purpose of the series. I know, I'm _just wondering_. -- With Best Regards, Andy Shevchenko
On Sun, 30 Nov 2025 21:44:46 +0200 Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote: > On Sun, Nov 30, 2025 at 01:16:19PM -0500, Yury Norov wrote: > > On Sat, Nov 29, 2025 at 10:30:23PM +0200, Andy Shevchenko wrote: > > > On Sat, Nov 29, 2025 at 02:53:02PM -0500, Yury Norov (NVIDIA) wrote: > > > > Tracing is a half of the kernel.h in terms of LOCs, although it's a > > > > self-consistent part. Move it to a separate header. > > > > > > > > This is a pure move, except for removing a few 'extern's. > > > > > > Yeah, I also have something similar (but half-baked) locally, the Q I wanted to > > > ask is why a separate header? We have already some of tracing headers. Doesn't > > > suit well? > > > > Just as said in the commit message - this part is more or less > > self-consistent and debugging-oriented. If someone needs to just > > throw trace_printk() in their driver, they will not have to pull > > all the heavy tracing machinery. > > Please, add a summary of this to it. It will be much clearer and based on it > I agree with your judgement. It is worth checking whether the files get included anyway, and whether it really makes that much difference. Fiddling with kernel.h and extracting small 'leaf' headers from it is also unlikely to make a big difference. Try adding a syntax error to (say) sys/ioctl.h and see where it is included from the first time - I suspect you'll be surprised. Working on that include list might be more fruitful (in reducing build times). David
On Sun, Nov 30, 2025 at 11:09:25PM +0000, david laight wrote: > On Sun, 30 Nov 2025 21:44:46 +0200 > Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote: ... > It is worth checking whether the files get included anyway, and whether it > really makes that much difference. > > Fiddling with kernel.h and extracting small 'leaf' headers from it is also > unlikely to make a big difference. It makes a big difference for the kernel.h and its (ab)users. Especially when we have cyclic dependencies and "include everything" cases due to other _headers_ including kernel.h. > Try adding a syntax error to (say) sys/ioctl.h and see where it is included > from the first time - I suspect you'll be surprised. > Working on that include list might be more fruitful (in reducing build times). kernel.h elimination (in the form it exists right now) is very fruitful. However, you may help with the (say) ioctl.h or whatever you consider really fruitful, we all will thank you (no jokes). -- With Best Regards, Andy Shevchenko
On Mon, 1 Dec 2025 04:50:42 +0200
Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote:
> On Sun, Nov 30, 2025 at 11:09:25PM +0000, david laight wrote:
> > On Sun, 30 Nov 2025 21:44:46 +0200
> > Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote:
>
> ...
> kernel.h elimination (in the form it exists right now) is very fruitful.
> However, you may help with the (say) ioctl.h or whatever you consider
> really fruitful, we all will thank you (no jokes).
>
This is the first #include path for ioctl.h
In file included from ../include/asm-generic/ioctl.h:5,
from ./arch/x86/include/generated/uapi/asm/ioctl.h:1,
from ../include/uapi/linux/ioctl.h:5,
from ../include/uapi/linux/random.h:12,
from ../include/linux/random.h:10,
from ../include/linux/nodemask.h:94,
from ../include/linux/numa.h:6,
from ../include/linux/cpumask.h:17,
from ../arch/x86/include/asm/paravirt.h:21,
from ../arch/x86/include/asm/irqflags.h:102,
from ../include/linux/irqflags.h:18,
from ../include/linux/spinlock.h:59,
from ../include/linux/swait.h:7,
from ../include/linux/completion.h:12,
from ../include/linux/crypto.h:15,
from ../arch/x86/kernel/asm-offsets.c:9:
Get past that and sched.h => processor.h => cpuid/api.h also
gets you to paravirt.h.
I suspect a lot of headers get pulled in like that.
David
On Mon, Dec 01, 2025 at 10:16:58AM +0000, david laight wrote: > On Mon, 1 Dec 2025 04:50:42 +0200 > Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote: > > On Sun, Nov 30, 2025 at 11:09:25PM +0000, david laight wrote: > > > On Sun, 30 Nov 2025 21:44:46 +0200 > > > Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote: ... > > kernel.h elimination (in the form it exists right now) is very fruitful. > > However, you may help with the (say) ioctl.h or whatever you consider > > really fruitful, we all will thank you (no jokes). > > > > This is the first #include path for ioctl.h > > In file included from ../include/asm-generic/ioctl.h:5, > from ./arch/x86/include/generated/uapi/asm/ioctl.h:1, > from ../include/uapi/linux/ioctl.h:5, > from ../include/uapi/linux/random.h:12, > from ../include/linux/random.h:10, > from ../include/linux/nodemask.h:94, > from ../include/linux/numa.h:6, > from ../include/linux/cpumask.h:17, > from ../arch/x86/include/asm/paravirt.h:21, > from ../arch/x86/include/asm/irqflags.h:102, > from ../include/linux/irqflags.h:18, > from ../include/linux/spinlock.h:59, > from ../include/linux/swait.h:7, > from ../include/linux/completion.h:12, > from ../include/linux/crypto.h:15, > from ../arch/x86/kernel/asm-offsets.c:9: > > Get past that and sched.h => processor.h => cpuid/api.h also > gets you to paravirt.h. > I suspect a lot of headers get pulled in like that. And several headers like ioctl.h that is "pull half of everything". device.h, for example. So, you can start untangling them piece by piece. Not sure how [1] is actual right now, but I believe plenty of those can still be used. [1]: https://lwn.net/ml/linux-kernel/YdIfz+LMewetSaEB@gmail.com/ -- With Best Regards, Andy Shevchenko
On Sun, 30 Nov 2025 21:44:46 +0200 Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote: > On Sun, Nov 30, 2025 at 01:16:19PM -0500, Yury Norov wrote: > > On Sat, Nov 29, 2025 at 10:30:23PM +0200, Andy Shevchenko wrote: > > > On Sat, Nov 29, 2025 at 02:53:02PM -0500, Yury Norov (NVIDIA) wrote: > > > > Tracing is a half of the kernel.h in terms of LOCs, although it's a > > > > self-consistent part. Move it to a separate header. > > > > > > > > This is a pure move, except for removing a few 'extern's. > > > > > > Yeah, I also have something similar (but half-baked) locally, the Q I wanted to > > > ask is why a separate header? We have already some of tracing headers. Doesn't > > > suit well? > > > > Just as said in the commit message - this part is more or less > > self-consistent and debugging-oriented. If someone needs to just > > throw trace_printk() in their driver, they will not have to pull > > all the heavy tracing machinery. > > Please, add a summary of this to it. It will be much clearer and based on it > I agree with your judgement. Agreed. Please update the change log stating that the tracing code in kernel.h is only used for quick debugging purposes and is not used for the normal tracing utilities. -- Steve
© 2016 - 2025 Red Hat, Inc.