[PATCH libpciaccess] linux: support 32 bit PCI domains
agoins at nvidia.com
Sat Aug 26 01:03:51 UTC 2017
On Wed, 12 Jul 2017, Adam Jackson wrote:
> On Wed, 2017-07-12 at 19:30 +0200, Mark Kettenis wrote:
> > > Date: Tue, 11 Jul 2017 10:32:19 -0700
> > > From: Stephen Hemminger <stephen at networkplumber.org>
> > >
> > > Yes, binary compatibility is a problem. Putting additional data at end
> > > of structure is possible, but as was raised in the thread, this won't work
> > > if some code puts the structure on the stack.
> > >
> > > An alternative (like pci-utils) would be to have a sacrificial element.
> > > BSD PCI code would also have to change to do this.
> > As explained in the thread, this is still an ABI break. There is not
> > much point in making these changes if you have to bump the shared
> > library major anyway.
> 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.
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.
> - ajax
More information about the xorg-devel