libpciaccess on GNU/Hurd

[Samuel Thibault]

Hello,

Adam Jackson, le mer. 07 nov. 2018 12:04:52 -0500, a ecrit:
> 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,

Why would it _need_ to be a kernel service?

> The 'x86' backend is fundamentally broken (as you've noticed)

How do you see it broken? (considering that the concurrent access issue
is solved by moving it to a central place)

> 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.

Well, there is more to it than just protecting concurrent use of the
x86 access code: what we call pci arbiter would also allow to specify
which application/user is allowed to see/access what, forward it in
containers, possibly using an iommu to make it secure, etc.

Samuel