[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Full-time developer available
From: |
Samuel Thibault |
Subject: |
Re: Full-time developer available |
Date: |
Sat, 19 Sep 2015 01:30:15 +0200 |
User-agent: |
Mutt/1.5.21+34 (58baf7c9f32f) (2010-12-30) |
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
- Re: Full-time developer available, (continued)
- Re: Full-time developer available, Robert Millan, 2015/09/16
- Re: Full-time developer available, Diego Nieto Cid, 2015/09/16
- Re: Full-time developer available, Samuel Thibault, 2015/09/16
- Re: Full-time developer available, Diego Nieto Cid, 2015/09/17
- Re: Full-time developer available, Samuel Thibault, 2015/09/17
- Re: Full-time developer available, Diego Nieto Cid, 2015/09/17
- Re: Full-time developer available, Samuel Thibault, 2015/09/17
- Re: Full-time developer available, Robert Millan, 2015/09/17
- Re: Full-time developer available, Samuel Thibault, 2015/09/17
- Re: Full-time developer available, Robert Millan, 2015/09/18
- Re: Full-time developer available,
Samuel Thibault <=
- PCI device handling (was: Full-time developer available), Olaf Buddenhagen, 2015/09/18
- Sound translator / PCI device handling (was: Full-time developer available), Olaf Buddenhagen, 2015/09/18
- Re: Sound translator / PCI device handling, Robert Millan, 2015/09/19
- Re: Sound translator / PCI device handling, Antti Kantee, 2015/09/19
- Re: Sound translator / PCI device handling, Olaf Buddenhagen, 2015/09/23
- Re: Sound translator / PCI device handling, Antti Kantee, 2015/09/24
- Sound translator / PCI device handling (was: Full-time developer available), Olaf Buddenhagen, 2015/09/18
- Re: Sound translator / PCI device handling (was: Full-time developer available), Samuel Thibault, 2015/09/19
- Sound translator (was: Full-time developer available), Olaf Buddenhagen, 2015/09/18
- Re: Sound translator, Robert Millan, 2015/09/19