"Michael S. Tsirkin" <[email protected]> writes: > On Wed, Dec 07, 2022 at 07:25:49AM +0100, 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? > > I'm ok with pci_defs.h > However, I note that most headers including pci.h don't really > need it. Consider include/hw/virtio/virtio-iommu.h all it needs is > PCIBus typedef this is available from qemu/typedefs.h > So if you are poking at this, want to clean that area up generally?
I looked into this, which made me reconsider my pci_defs.h idea. Instead of splitting off pci_defs.h for PCI_NUM_REGIONS and similar stuff (which stuff exactly?), I'm going to split off pci_device.h for PCIDevice & friends. [...]
