Re: [GIT PULL] tracing: Updates for 7.2

[Willy Tarreau]

On Fri, Jun 19, 2026 at 01:55:15PM -0700, Linus Torvalds wrote:
> On Fri, 19 Jun 2026 at 13:28, Thomas Gleixner <tglx@xxxxxxxxxx> wrote:
> >
> > 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.
> 
> We tend to do a lot of inline functions, and that often makes it
> impossible to do the simple "just forward-declare the type".
> 
> And often there are fairly good reasons for the inline functions, in
> that they tend to be much safer than macros, both for type checking
> and for the whole "use argument once" reason (they also avoid compiler
> warnings when the argument _isn't_ used).

In haproxy we've had a hard time dealing with circular dependencies and
build time issue for a while and a few years ago we found what looks
like a mostly optimal arrangement. Each include file exists in two
versions:
  - one suffixed with "-t" which contains only type declarations
    (#define as well as enums, structs etc)
  - the main one without "-t" that includes the first one and contains
    declarations (extern variables & functions as well as inline)

And all this with a strict rule: no -t file may ever include any of the
other ones. It now works pretty well, and we could significantly reduce
the depth of includes and no longer need to resolve broken inline-to-inline
references. And we discovered that many C files don't even need the main
file and only need types definitions, further reducing build time. Also
we figured that certain -t files only included another one for a single
struct definition that appeared as a pointer, so these were sometimes
replaced with just a forward-declaration before use and that was done.

We made mistakes too, most of our macros that replaced inline functions
tend to be in the main files instead of the -t one as the rule implies,
encouraging to place further macro definitions at the wrong place. But
moving them is no big deal.

If I would change something, it would probably be around long macro
definitions (e.g. series of flags) that are often not needed by other
-t files and only by functions. It's just difficult for me to express
that distinction in a way that's clear enough for eveyrone to respect,
but this could definitely further reduce the preprocessing time of the
types-only "-t" files.

Willy