From: Markus Armbruster <armbru@redhat.com>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Bernhard Beschow <shentey@gmail.com>,
qemu-devel@nongnu.org, marcel.apfelbaum@gmail.com,
jonathan.cameron@huawei.com, philmd@linaro.org
Subject: Re: [PATCH v2 0/7] include/hw/pci include/hw/cxl: Clean up includes
Date: Wed, 15 Feb 2023 14:28:34 +0100 [thread overview]
Message-ID: <871qmr9hx9.fsf@pond.sub.org> (raw)
In-Reply-To: 20221224063930-mutt-send-email-mst@kernel.org
"Michael S. Tsirkin" <mst@redhat.com> writes:
> On Fri, Dec 23, 2022 at 06:27:07AM +0100, Markus Armbruster wrote:
>> "Michael S. Tsirkin" <mst@redhat.com> writes:
>>
>> > On Thu, Dec 22, 2022 at 11:48:25AM +0100, Markus Armbruster wrote:
>> >> Bernhard Beschow <shentey@gmail.com> writes:
>> >>
>> >> > Am 22. Dezember 2022 10:03:23 UTC schrieb Markus Armbruster <armbru@redhat.com>:
>> >> >>Back in 2016, we discussed[1] rules for headers, and these were
>> >> >>generally liked:
>> >> >>
>> >> >>1. Have a carefully curated header that's included everywhere first. We
>> >> >> got that already thanks to Peter: osdep.h.
>> >> >>
>> >> >>2. Headers should normally include everything they need beyond osdep.h.
>> >> >> If exceptions are needed for some reason, they must be documented in
>> >> >> the header. If all that's needed from a header is typedefs, put
>> >> >> those into qemu/typedefs.h instead of including the header.
>> >> >>
>> >> >>3. Cyclic inclusion is forbidden.
>> >> >
>> >> > Sounds like these -- useful and sane -- rules belong in QEMU's coding style. What about putting them there for easy reference?
>> >>
>> >> Makes sense. I'll see what I can do. Thanks!
Commit f07ceffdf50.
>> > It would be even better if there was e.g. a make target
>> > pulling in each header and making sure it's self consistent and
>> > no circularity. We could run it e.g. in CI.
>>
>> Yes, that would be nice, but the problem I've been unable to crack is
>> deciding whether a header is supposed to compile target-independently or
>> not. In my manual testing, I use trial and error: if it fails to
>> compile target-independently, compile for all targets. This is s-l-o-w.
To spice things up, we also have headers that provide additional
contents in target-dependent context. These need to be tested in both
contexts.
> Yes and it's annoying for developers too.
> Do we want to come up with a scheme for target-dependent files?
> Name them target-X or put in a target/ directory?
I'd be in favour. Sadly, I'm not able to push such an effort myself.
> We could also write checkpatch rules to disallow
> including target specific headers in target independent files then.
Fortunately, that's pretty unlikely to compile :)
>> The other problem, of course, is coding it up in Meson. I haven't even
>> tried.
next prev parent reply other threads:[~2023-02-15 13:28 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-22 10:03 [PATCH v2 0/7] include/hw/pci include/hw/cxl: Clean up includes Markus Armbruster
2022-12-22 10:03 ` [PATCH v2 1/7] include/hw/pci: Break inclusion loop pci_bridge.h and cxl.h Markus Armbruster
2022-12-22 10:03 ` [PATCH v2 2/7] include/hw/cxl: Move typedef PXBDev to cxl.h, and put it to use Markus Armbruster
2022-12-22 10:03 ` [PATCH v2 3/7] include/hw/cxl: Include hw/cxl/*.h where needed Markus Armbruster
2022-12-22 10:03 ` [PATCH v2 4/7] include/hw/pci: Clean up a few things checkpatch.pl would flag Markus Armbruster
2022-12-22 10:03 ` [PATCH v2 5/7] include/hw/pci: Split pci_device.h off pci.h Markus Armbruster
2022-12-22 10:03 ` [PATCH v2 6/7] include/hw/pci: Include hw/pci/pci.h where needed Markus Armbruster
2022-12-22 10:03 ` [PATCH v2 7/7] include/hw/cxl: Break inclusion loop cxl_pci.h and cxl_cdat_h Markus Armbruster
2022-12-22 10:38 ` [PATCH v2 0/7] include/hw/pci include/hw/cxl: Clean up includes Bernhard Beschow
2022-12-22 10:48 ` Markus Armbruster
2022-12-22 19:22 ` Michael S. Tsirkin
2022-12-23 5:27 ` Markus Armbruster
2022-12-23 10:33 ` Bernhard Beschow
2022-12-24 11:43 ` Michael S. Tsirkin
2023-02-15 13:28 ` Markus Armbruster [this message]
2023-02-15 15:05 ` Philippe Mathieu-Daudé
2023-02-15 17:21 ` Markus Armbruster
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=871qmr9hx9.fsf@pond.sub.org \
--to=armbru@redhat.com \
--cc=jonathan.cameron@huawei.com \
--cc=marcel.apfelbaum@gmail.com \
--cc=mst@redhat.com \
--cc=philmd@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=shentey@gmail.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.