[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Full-time developer available

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]