From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: "Michael S. Tsirkin" <mst@redhat.com>,
Markus Armbruster <armbru@redhat.com>,
qemu-devel@nongnu.org, imp@bsdimp.com, kevans@freebsd.org,
ben.widawsky@intel.com, jonathan.cameron@huawei.com,
kbastian@mail.uni-paderborn.de, jasowang@redhat.com,
michael.roth@amd.com, kkostiuk@redhat.com, tsimpson@quicinc.com,
palmer@dabbelt.com, alistair.francis@wdc.com,
bin.meng@windriver.com, qemu-riscv@nongnu.org, philmd@linaro.org,
Bin Meng <bmeng.cn@gmail.com>
Subject: Re: [PATCH v3 1/1] include: Don't include qemu/osdep.h
Date: Thu, 12 Jan 2023 16:30:20 +0000 [thread overview]
Message-ID: <Y8A1nNp/JieSDgIP@redhat.com> (raw)
In-Reply-To: <CAFEAcA_EP2_0vm8r=12DBTG4a7X7aMYAy2x+K7YctZmSZWTv2g@mail.gmail.com>
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.
> > All the header files could just reference the specific
> > system headers they care about instead of making everything
> > from osdep.h visible in their namespace.
>
> 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.)
Yeah, its not entirely straightforward, though our CI will catch
that on our most important target platforms.
With regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
next prev parent reply other threads:[~2023-01-12 16:30 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-12 11:50 [PATCH v3 0/1] Clean up includes Markus Armbruster
2023-01-12 11:50 ` [PATCH v3 1/1] include: Don't include qemu/osdep.h Markus Armbruster
2023-01-12 13:51 ` Michael S. Tsirkin
2023-01-12 13:56 ` Michael S. Tsirkin
2023-01-12 14:47 ` Markus Armbruster
2023-01-12 17:37 ` Michael S. Tsirkin
2023-01-12 17:44 ` Daniel P. Berrangé
2023-01-12 17:47 ` Michael S. Tsirkin
2023-01-12 14:52 ` Daniel P. Berrangé
2023-01-12 15:58 ` Peter Maydell
2023-01-12 16:07 ` Daniel P. Berrangé
2023-01-12 16:20 ` Peter Maydell
2023-01-12 16:30 ` Daniel P. Berrangé [this message]
2023-01-12 16:38 ` Peter Maydell
2023-01-12 17:43 ` Michael S. Tsirkin
2023-01-12 17:30 ` Jonathan Cameron
2023-01-12 17:30 ` Jonathan Cameron via
2023-01-12 17:41 ` Michael S. Tsirkin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Y8A1nNp/JieSDgIP@redhat.com \
--to=berrange@redhat.com \
--cc=alistair.francis@wdc.com \
--cc=armbru@redhat.com \
--cc=ben.widawsky@intel.com \
--cc=bin.meng@windriver.com \
--cc=bmeng.cn@gmail.com \
--cc=imp@bsdimp.com \
--cc=jasowang@redhat.com \
--cc=jonathan.cameron@huawei.com \
--cc=kbastian@mail.uni-paderborn.de \
--cc=kevans@freebsd.org \
--cc=kkostiuk@redhat.com \
--cc=michael.roth@amd.com \
--cc=mst@redhat.com \
--cc=palmer@dabbelt.com \
--cc=peter.maydell@linaro.org \
--cc=philmd@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=qemu-riscv@nongnu.org \
--cc=tsimpson@quicinc.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.