Re: [GIT PULL] tracing: Updates for 7.2

[Thomas Gleixner <tglx@kernel.org>]

On Fri, Jun 19 2026 at 12:07, Linus Torvalds wrote:
> On Fri, 19 Jun 2026 at 11:30, Sebastian Andrzej Siewior
> <bigeasy@linutronix.de> wrote:
> But in general, if the question is "should we split this header file
> up if it's straightforward and easy", the answer is *ALWAYS* a
> resounding "YES".

Full ACK.

> Most of the time it's just a pain to unravel all the type
> dependencies. This case look strivial compared to some we've done.
>
> One of the things I at one point hoped sparse would do was a "you're
> including this header for no good reason" tooling.
>
> But it's non-trivial to do, particularly with lots of different
> architectures that aren't very consistent in where they declare or use
> things.

That's only one part of the overall problem.

People are really careless when they add new things. It took me
literally weeks to handle all the 0-day compile fallout when I tried to
disentangle the __percpu mess so that a header using a __percpu
annotation in a struct declaration is not required to include the world
and running into recursive header hell.

See c06cd66387da ("percpu: Sanitize __percpu_qual include hell")

I'm still fighting to resolve the last remaining issue to get rid of the
asm/xtime.h dependency in some other cleanup project. That header is so
deeply ingrained in some of our header chains for the very wrong
reasons.

I've tried to utilize AI for analyzing it, but that ended up in an even
bigger disaster.

One thing I'm seeing is that the kernel is patently bad in separating
data type declarations from actual APIs, where the APIs usually just
need a forward declaration of the pointer type. Ditto for struct
declarations with pointer types. 

After doing quite some of these disentanglements manually and trying to
utilize all kinds of tooling, I still have no good answer to this
unfortunately.

Thanks,

        tglx