Damien Zammit, le mer. 04 sept. 2019 19:42:03 +1000, a ecrit:
> 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 (?)
I'm not sure what question remains? As you said the arbiter gets I/O
access, other processes go through the arbiter.
> > 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.
For sub-hurds, the usual way is to expose a new device on the master
device port.
Here we don't have a device, but a mere node with RPCs. Actually we
could want the same for sharing a TCP/IP stack and such exposition of a
mere node with RPCs.
I'm wondering whether we should rather add to the master device port the
dir_lookup RPC, and we would give a guest/host path mapping to the boot
script, similarly to the guest/host device mapping. Inside the guest we
would settrans on /servers/bus/pci some translator that opens the master
device port and dir_lookup("servers/bus/pci") on it.
Samuel
