|
From: | Robert Millan |
Subject: | Re: Full-time developer available |
Date: | Fri, 18 Sep 2015 21:14:30 +0200 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 |
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! 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. CPUs don't know how to "atomic test and set" on I/O space and pthread_mutex_t only cares about other threads in the same process. 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? Would a giant lock for all I/O serve the needs of all inb/outb users? Would it be possible to solve this in a portable way? -- Robert Millan
[Prev in Thread] | Current Thread | [Next in Thread] |