Re: [PATCH libpciaccess] hurd: Clients or nested arbiters don't touch ioports

[Damien Zammit]

Hi Samuel,

I don't understand how a client/nested arbiter could be currently using these 
methods
successfully because the hurd access method would fail to enable io via 
x86_enable_io().
That is how we determine if we are a client not a master, by attempting to grab
all io ports and getting rejected the second time by the kernel.

So any subsequent pci_io_* calls would all be failing anyway via hurdish access 
method?

Damien

On 25/8/22 6:58 am, Samuel Thibault wrote:
> Damien Zammit, le mar. 23 août 2022 08:36:56 +0000, a ecrit:
>> I tested this patch and linked it to both pci-arbiter.static
>> and rumpdisk.static, everything still works.
>
> Did you try Xorg? It uses pci_io_read32 & alike.
>
>> +    .open_legacy_io = NULL,
>> +    .close_io = NULL,
>> +    .read32 = NULL,
>> +    .read16 = NULL,
>> +    .read8 = NULL,
>> +    .write32 = NULL,
>> +    .write16 = NULL,
>> +    .write8 = NULL,
>
> That would break it.
>
> When it was mentioned on IRC, I though this was about an mmio
> read/write, which would have to go through PCI drivers etc. since it's
> actually i/o ports we just *have* to do ins/outs. Most modern hardware
> use mmio, but legacy, e.g. vga/vesa/etc. use these I/O.
>
> Samuel
>