Hi, On Fri, Sep 18, 2015 at 09:14:30PM +0200, Robert Millan wrote: > El 17/09/15 a les 23:25, Samuel Thibault ha escrit: > >Robert Millan, le Thu 17 Sep 2015 21:55:32 +0200, a écrit :
> >>My understanding is there's no need for an arbiter / multiplexer > >>as long as all the code playing with PCI devices is well-aware of its > >>limits. > > > >Yes, for the daily work, the driver can behave well. But to know where > >the PCI registers are, you need to read that from the config. And that > >includes unsafe concurrent accesses (i.e. write to a register, read the > >value). See inside libpciaccess, x86_pci.c which does inl(); outl(); > >inl(); outl(); > > Ah, I see what you mean. This seems like a bug in libpciaccess... the routines > aren't even thread-safe! > > It looks like a generic problem, affecting all uses of libpciaccess (on other > OS too). I guess it's been tolerated so far because there isn't any readily > available solution. Note that the original purpose of libpciaccess was to get rid of register poking in the X server, and use proper system-provided PCI access methods instead. The register poking backend was added after all (after some initial reservations) for the sake of the Hurd, because we just don't *have* a proper PCI access method yet... That's a kludge, though -- the plan always has been to implement a proper PCI server in the Hurd at some point, and then to provide a libpciaccess backend to access it. Same for other systems using the register-poking backend. -antrik-
