bug-hurd
[Top][All Lists]
Advanced

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

Re: PCI Arbiter status


From: Damien Zammit
Subject: Re: PCI Arbiter status
Date: Wed, 4 Sep 2019 19:42:03 +1000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0

On 4/9/19 6:10 am, Joan Lledó wrote:

> 3- In libpciaccess upstream there are some commits by Damien Zammit,
> one of them with the new modules for the Hurd. I wonder: this new
> module expects to be used from both user tasks and the translator?

There are currently two modes of operation in libpciaccess for Hurd,
one uses io-ports (x86) and one uses the hurdish methods.
The first process to grab the pci cfg io ports takes a lock in gnumach,
(which is assumed to be the arbiter using libpciaccess).
This prevents libpciaccess from using the io-port access method more than once.
I think any consequent processes accessing pci should do so through the arbiter
translator and it should be the only use of libpciaccess with the hurdish 
method.
However, other user processes (in theory) could also use libpciaccess with the
hurdish access method and would still function (not sure about simultaneous 
access).
Perhaps Samuel can comment more on this (?)

> 4- About pciutils, is something ours in upstream? Damien, did you send
> patches to pciutils?

I have not sent patches to pciutils, but I do seem to have a git branch
that I was working on - based on upstream.  I'm happy to share patches.
I think it was based on your existing work, Joan.

> Is this the only change you guys think it should be done in the
> interface? Are the other operations OK for you?

I think we need to discuss how the arbiter is supposed to work,
so that we can be sure that things like sub-hurds can work as expected.

--
Damien Zammit



reply via email to

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