bug-hurd
[Top][All Lists]
Advanced

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

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


From: Damien Zammit
Subject: Re: [PATCH libpciaccess] hurd: Clients or nested arbiters don't touch ioports
Date: Wed, 24 Aug 2022 00:50:29 +0000

Hi,

On 23/8/22 10:23 pm, Joan Lledó wrote:
> El 23/8/22 a les 10:36, Damien Zammit ha escrit:
>> @@ -600,14 +599,14 @@ static const struct pci_system_methods 
>> hurd_pci_methods = {
>>       .read = pci_device_hurd_read,
>>       .write = pci_device_hurd_write,
>>       .fill_capabilities = pci_fill_capabilities_generic,
>> -    .open_legacy_io = pci_device_x86_open_legacy_io,
>> -    .close_io = pci_device_x86_close_io,
>> -    .read32 = pci_device_x86_read32,
>> -    .read16 = pci_device_x86_read16,
>> -    .read8 = pci_device_x86_read8,
>> -    .write32 = pci_device_x86_write32,
>> -    .write16 = pci_device_x86_write16,
>> -    .write8 = pci_device_x86_write8,
>> +    .open_legacy_io = NULL,
>> +    .close_io = NULL,
>> +    .read32 = NULL,
>> +    .read16 = NULL,
>> +    .read8 = NULL,
>> +    .write32 = NULL,
>> +    .write16 = NULL,
>> +    .write8 = NULL,
>>       .map_legacy = pci_device_hurd_map_legacy,
>>       .unmap_legacy = pci_device_hurd_unmap_legacy,
>>   };
>
> Those functions are declared at x86_pci.h precisely b/c they need to be
> known for hurd_pci.c. If you stop calling them you should remove them
> also from x86_pci.h and make them static in x86_pci.c
OK, I could remove that as well, but this patch is still valid on its own.

Do we really need to touch x86 method again?  It may make sense
to allow those functions to be called in case we change our design again.

I noticed that open_legacy_io has a way to register handles per io port range.
Perhaps we could keep a list of ranges being used and reserve them from being 
shared,
so that only one client can use each device at a time, and return EBUSY when 
already taken?
And then we could restrict ioperm to each range.  Or is that going too far?
I think we would need an alternative x86 method for that.

Damien




reply via email to

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