[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: How to best make include/hw/pci/pcie_sriov.h self-contained
From: |
Markus Armbruster |
Subject: |
Re: How to best make include/hw/pci/pcie_sriov.h self-contained |
Date: |
Fri, 09 Dec 2022 14:09:35 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) |
"Michael S. Tsirkin" <mst@redhat.com> 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.
[...]