Re: [PATCH v3 1/1] include: Don't include qemu/osdep.h

[Peter Maydell <peter.maydell@linaro.org>]

On Thu, 12 Jan 2023 at 16:30, Daniel P. Berrangé <berrange@redhat.com> wrote:
>
> On Thu, Jan 12, 2023 at 04:20:36PM +0000, Peter Maydell wrote:
> > On Thu, 12 Jan 2023 at 16:08, Daniel P. Berrangé <berrange@redhat.com> wrote:
> > > I think the challenge is that osdep.h is too big as it exists
> > > today. The stuff the needs to come before system headers is
> > > actually little more than config-host.h and a few #defines
> > > most of which are specific to windows. If those critical
> > > #defines went into config-host.h, then we could have a rule
> > > 'config-host.h' must be included in all .c files as the first
> > > thing.
> >
> > This doesn't seem much different to the rules we have today,
> > except you've renamed osdep.h to config-host.h...
>
> If the QEMU header files all contain #includes for the
> system headers they rely on, then when tools are validating
> code in the header, they can stand a better chance of being
> able to resolve all the types. Though it'll still fail if
> some of the system header pieces only get exposed as a result
> of config-host.h macros, but that's relatively few, compared
> to today where amost nothing resolves if yuo validate the
> headers files in isolation.

Yeah, but I don't want QEMU header files to contain
lots of includes for system header files, because of...

> > There are some complicated things in there, not always
> > limited to Windows. Also where there is some header
> > that needs a platform-specific workaround I prefer that
> > that header is pulled in by osdep.h. This avoids the
> > failure mode of "developer working on Linux directly
> > includes some-system-header.h; works fine on their machine,
> > but doesn't work on oddball-platform where the header
> > needs a workaround". (For instance, handling "sys/mman.h
> > on this system doesn't define MAP_ANONYMOUS", or the
> > backcompat stuff in glib-compat.h.)

...this. So we'd have to have config-host.h include all
the system headers we're working around anyway.

-- PMM