On Thu, 12 Jan 2023 at 16:30, Daniel P. Berrangé <[email protected]> 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é <[email protected]> > > 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
