libpciaccess on GNU/Hurd

[Adam Jackson]

On Mon, 2018-11-05 at 22:56 +1100, Damien Zammit wrote:

> I wish to propose an additional api call to libpciaccess.
> Before I submit a patch, I wish to get some feedback from the devs.
> 
> In GNU/Hurd currently, applications use the x86 backend from
> libpciaccess. This poses concurrency issues when multiple applications
> run at the same time accessing pci.
> Thus we want to make libpciaccess do operations through an arbiter.
> The pci arbiter would use libpciaccess to access the x86 methods, but
> then we wish to make applications use the hurd method on top of that.

What I'd do instead is make a kernel service for this and have the Hurd
backend call that, because that'd look like what every other sane OS
does. The 'x86' backend is fundamentally broken (as you've noticed) and
it would be preferable if none of the supported OSes need it anymore.
Hurd being one of the last that needs it...

If you don't want to fix Hurd's kernel, then wat I'd do instead is
create a Hurd backend inside libpciaccess. Change x86_pci_methods to
_pci_hidden instead of static, create a hurd_pci_methods vtable that
takes whatever arbitration lock you want (some lock file in /tmp or
whatever) and then calls through to the x86_pci_methods vtable.

- ajax