Re: [COMMITTED] libpoke, poke: support for volatile/non-volatile IO spaces

[Jose E. Marchesi]

> On Sun, Sep 29, 2024 at 10:07:20PM GMT, Jose E. Marchesi wrote:
>> 
>> > 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?
>
>
> As part of `uint64_t (*get_flags) (void *dev);' function?

That callback is documented in the public API as:

  /* Return the flags of the device, as it was opened.  */
  uint64_t (*get_flags) (void *dev);

Which is not what volatile_by_default is.