poke-devel
[Top][All Lists]
Advanced

[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);
>>  



reply via email to

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