Robert Millan, le Fri 18 Sep 2015 21:14:30 +0200, a écrit : > 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 : > >>As for the rest of PCI devices, AFAICT they're free to be used by whoever > >>wants them. 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!
Well, yes, but libpciaccess can't really protect its accesses from access from other tools. It could still protect itself from itself, indeed. > It looks like a generic problem, affecting all uses of libpciaccess (on other > OS too). I guess only the Hurd uses the x86 backend. > This makes me think on MAP_SHARED mmap of some system-wide file e.g. > /run/io.lock or such, then an "inter-process mutex" on top of that. Does > this look sane? That is defined by posix for semaphores, you just need to pass pshared=1 to sem_init. It isn't supported yet in GNU/hurd. > Would a giant lock for all I/O serve the needs of all > inb/outb users? Err, you'll probably prefer only a lock on the config space ports, but yes. > Would it be possible to solve this in a portable way? It would probably be more portable to rather use a lock on a file in e.g /run/lock. Samuel
