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 _______________________________________________ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel