Re: [PATCH] Add missing includes to headers

[Stefano Brivio <sbrivio@redhat.com>]

On Mon, 23 Feb 2026 16:33:32 +1100
David Gibson <david@gibson.dropbear.id.au> wrote:

> On Thu, Feb 19, 2026 at 01:44:54PM -0500, Peter Foley wrote:
> > Support build systems like bazel that check that headers are
> > self-contained.
> > 
> > Signed-off-by: Peter Foley <pefoley@google.com>  
> 
> There are kind of two schools of thoughts on headers.  One is that
> every header should #include anything it relies on.  The other is that
> headers should #include nothing, and .c files should includde
> everything they need in the right order.  The advantages of the second
> approach are that it makes it easier to keep #includes in .c files
> minimal, and makes circular dependencies more obvious and easier to
> dientanble.
> 
> We've kinda sorta been using approach two in passt, but not entirely,
> and honestly, it's not really working.

I would argue it *is* pretty much working, because it builds without
warnings against glibc and musl, with several versions of gcc and
Clang, on a large number of distributions and architectures, which is
what it needs to do.

There are currently two warnings with (unreleased) gcc 16-ish and
glibc, I still have to post patches for them, but they have nothing to
do with includes.

That being said, sure, it's not either approach and admittedly kind of
arbitrary and rather messy.

> So I'm happy to convert to the
> former approach.  However, if we're adding #includes in the headers so
> they're self contained, then we should be able to also *remove* a
> bunch of #includes from .c files (and other .h files) which were
> previously only there to satisfy the indirect dependencies.

Just for clarity, while I agree, this patch does *not* magically make
that Peter's job. :)

I'd say that making it build with Bazel is more useful at this stage so
I would happily accept this patch by itself (I just need to find a
moment to try out builds on musl and on a couple of distributions,
first).

The cleanup you propose can also be done independently at a later
point, also because I'm fairly sure there are a bunch of left-over
includes (also/mostly from myself) even before this change.

Note that this kind of cleanup would also take a bit of testing that
we currently can't automate, for example building against musl on
Alpine or Void Linux.

-- 
Stefano