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

[Andy Shevchenko <andriy.shevchenko@linux.intel.com>]

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