bug-hurd
[Top][All Lists]
Advanced

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

Re: PCI Arbiter status


From: Samuel Thibault
Subject: Re: PCI Arbiter status
Date: Thu, 5 Sep 2019 01:20:27 +0200
User-agent: NeoMutt/20170609 (1.8.3)

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



reply via email to

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