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 <[email protected]> > > > > > > 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. Thanks, Alex > - ajax _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
