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
