qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: "Philippe Mathieu-Daudé" <philmd@linaro.org>
Cc: Markus Armbruster <armbru@redhat.com>,
	qemu-devel@nongnu.org, Marcel Apfelbaum <marcel@redhat.com>
Subject: Re: How to best make include/hw/pci/pcie_sriov.h self-contained
Date: Wed, 7 Dec 2022 05:29:35 -0500	[thread overview]
Message-ID: <20221207052308-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <1184b1ab-c38a-b38b-b08c-637bc6b23bb5@linaro.org>

On Wed, Dec 07, 2022 at 10:02:53AM +0100, Philippe Mathieu-Daudé wrote:
> On 7/12/22 07:25, Markus Armbruster wrote:
> > pcie_sriov.h needs PCI_NUM_REGIONS from pci.h, but doesn't include it.
> > pci.h must be included before pcie_sriov.h or else compile fails.
> > 
> > Adding #include "pci/pci.h" to pcie_sriov would be wrong, because it
> > would close an inclusion loop: pci.h includes pcie.h (for
> > PCIExpressDevice) includes pcie_sriov.h (for PCIESriovPF) includes pci.h
> > (for PCI_NUM_REGIONS).
> > 
> > The obvious solution is to move PCI_NUM_REGIONS pci.h somewhere
> > pcie_sriov.h can include without creating a loop.
> > 
> > We already have a few headers that don't include anything: pci_ids.h,
> > pci_regs.h (includes include/standard-headers/linux/pci_regs.h, which
> > doesn't count), pcie_regs.h.  Moving PCI_NUM_REGIONS to one of these
> > would work, but it doesn't feel right.
> > 
> > We could create a new one, say pci_defs.h.  Just for PCI_NUM_REGIONS
> > feels silly.  So, what else should move there?
> 
> Sounds good to me. Eventually name it pci_standard_defs.h?

standard is not a good name for PCI_NUM_REGIONS. It falls out of
how QEMU represents things not directly out of the standard.
QEMU supports up to 6 BAR registers + 1 expansion ROM.
That's where the number comes from.
Same with PCI_ROM_SLOT - that's a QEMU convention.



> We can move the first 100 lines of pci.h there, PCI_ROM_SLOT,
> PCI_NUM_REGIONS, PCI HEADER_TYPE, PCI_NUM_PINS, cap_present, and eventually
> PCIINTxRoute & PCIReqIDType.

It's a good point that PCI_ROM_SLOT should live with PCI_NUM_REGIONS.

> > 
> > Any other ideas?
> > 
> > In case you wonder why I bother you with this...
> > 
> > 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.
> > 
> > I'm working on patches to get include/ closer to obeying 2.
> > 
> > [1] Message-ID: <87h9g8j57d.fsf@blackfin.pond.sub.org>
> >      https://lists.nongnu.org/archive/html/qemu-devel/2016-03/msg03345.html
> > 
> > 



  reply	other threads:[~2022-12-07 10:30 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-07  6:25 How to best make include/hw/pci/pcie_sriov.h self-contained Markus Armbruster
2022-12-07  9:02 ` Philippe Mathieu-Daudé
2022-12-07 10:29   ` Michael S. Tsirkin [this message]
2022-12-07 10:18 ` Michael S. Tsirkin
2022-12-09 13:09   ` 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=20221207052308-mutt-send-email-mst@kernel.org \
    --to=mst@redhat.com \
    --cc=armbru@redhat.com \
    --cc=marcel@redhat.com \
    --cc=philmd@linaro.org \
    --cc=qemu-devel@nongnu.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).