[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [COMMITTED] libpoke, poke: support for volatile/non-volatile IO spac
From: |
Jose E. Marchesi |
Subject: |
Re: [COMMITTED] libpoke, poke: support for volatile/non-volatile IO spaces |
Date: |
Sun, 29 Sep 2024 22:07:20 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) |
> Hi Jose.
>
> On Thu, Sep 19, 2024 at 11:38:38AM GMT, Jose E. Marchesi wrote:
>>
>> This patch introduces the notion of volatile vs. non-volatile IO
>> spaces in poke, which allows a smarter management of remaps.
>> Documentation and tests included.
>>
>> diff --git a/libpoke/libpoke.h b/libpoke/libpoke.h
>> index 63f91d1f..2228b522 100644
>> --- a/libpoke/libpoke.h
>> +++ b/libpoke/libpoke.h
>> @@ -1328,7 +1328,6 @@ typedef uint64_t pk_iod_off;
>> struct pk_iod_if
>> {
>> /* Return the name of this device interface. Cannot return NULL. */
>> -
>> const char *(*get_if_name) ();
>>
>> /* Determine whether the provided HANDLER is recognized as a valid
>> @@ -1358,6 +1357,12 @@ struct pk_iod_if
>> writes. */
>> int (*pwrite) (void *dev, const void *buf, size_t count, pk_iod_off
>> offset);
>>
>> + /* Return whether IO spaces implemented by this interface are
>> + "volatile" by default. Volatile IO spaces assume that their
>> + contents can change at any time, and not just as the result of
>> + write operations in this interface. */
>> + int (*volatile_by_default) (void *dev, const char *handler);
>> +
>
>
> Couldn't we get this functionality as a flag?
> Then we don't need to introduce a new function pointer, which is a change in
> both in API/ABI.
How would the IO device implementations communicate that flag?
>
>> /* Return the flags of the device, as it was opened. */
>> uint64_t (*get_flags) (void *dev);
>>