[PATCH libpciaccess] linux: support 32 bit PCI domains

[Adam Jackson]

On Fri, 2017-08-25 at 18:03 -0700, Alex Goins wrote:
> On Wed, 12 Jul 2017, Adam Jackson wrote:
> > As far as xserver is concerned, it's not an ABI break. We never embed a
> > struct pci_device in any ABI types, only pointers to them, and they're
> > always allocated by the library anyway so anyone sensitive to this
> > change would already be doing something wrong.
> 
> The X server uses it that way, but are we certain that other applications do as
> well? As Keith points out in the older thread, 'struct pci_device' isn't opaque
> and the documentation doesn't say that you can't populate it yourself or copy it
> around. I suppose it's unlikely that anyone is actually doing that, but it
> doesn't seem to be defined that you can't.

The consumers in Fedora appear to be:

% dnf -q repoquery --qf='%{sourcerpm}' --whatrequires 'libpciaccess.so.0()(64bit)' | sort -u
envytools-0.0-0.8.git20151030.fc26.src.rpm
fcoe-utils-1.0.32-1.fc26.src.rpm
hwloc-1.11.5-2.fc26.src.rpm
libdrm-2.4.82-1.fc26.src.rpm
libhbalinux-1.0.17-4.fc26.src.rpm
libpciaccess-0.13.4-4.fc26.src.rpm
libvirt-3.2.1-5.fc26.src.rpm
radeontool-1.6.3-9.fc26.src.rpm
radeontop-1.0-2.fc26.src.rpm
spice-vdagent-0.17.0-2.fc26.src.rpm
xorg-x11-drv-ati-7.9.0-1.fc26.src.rpm
xorg-x11-drv-intel-2.99.917-28.20160929.fc26.src.rpm
xorg-x11-server-1.19.3-4.fc26.src.rpm

I can't find any instance, in any of the above, of allocating a struct
pci_device on the stack or embedding it into another structure. The API
pushes you pretty naturally towards getting these handles from a match
or an iterator, so this isn't entirely surprising. For that matter,
other than xserver, I don't see any instance of any of the code caring
much about the domain field at all.

So: let's just extend the struct and add a big ol' warning about not
allocating it yourself.

> Either way it would be good to move forward with one solution or the other,
> since this is blocking functionality that's supported in the kernel and needed
> for some passthrough configurations.

Agreed. I think I want to make this a source compatibility break
though, rename the old field domain_16 and add a new domain_32, just to
make sure that consumers know what they're getting. Patch to follow
shortly.

- ajax