Re: [PATCH v2 hurd] pci: Add RPCs for taking and freeing io ports by BAR

[Samuel Thibault]

Joan Lledó, le jeu. 20 juil. 2023 22:38:42 +0200, a ecrit:
> I think your design is not compatible with nested arbiters. Correct me if
> I'm wrong, but AFAIK the arbiter doesn't know if it's a main or a nested
> arbiter, it's libpciaccess who handles that. So the arbiter code must be the
> same and work no matter if it's main or nested. In your design, the arbiter
> calls i386_io_perm_create(), that would work for the main arbiter but not
> for nested arbiters, because only one process can take the port, AFAIK.

No, several processes can take the port. The goal is only that only one
process enables the i/o perm range. The port itself can be forwarded
between arbiters.

> I think it should be libpciaccess x86 module who calls i386_io_perm_create()
> once per device during the initial probe. And store the resulting port at
> some place the arbiter can get it.

I don't think libpciaccess will like adding such hurd-specific
interface. But that's not really a problem: we can make pci-arbiter make
RPCs itself when the master device approach doesn't work. Actually, the
boot process could also even be taught to support i386_io_perm_create
by forwarding i/o permissions of the PCI devices to be handed to the
sub-hurd.

> I saw that `struct pci_device` contains a pointer `*user_data`. We could use
> that to pass the port from libpciaccess to the arbiter.

But we cannot use it all the time, only when pci-arbiter is the user of
libpciaccess. Other users such as Xorg, netdde, etc. may want to store
something else.

Samuel