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