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