Thread (36 messages) 36 messages, 9 authors, 2025-12-03

Re: [PATCH 3/3] tracing: move tracing declarations from kernel.h to a dedicated header

From: Yury Norov <yury.norov@gmail.com>
Date: 2025-11-30 18:16:21
Also in: dri-devel, intel-gfx, linux-modules, lkml

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:
quoted
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.
...
quoted
--- 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>
quoted
+#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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help