Re: ptimer use of bottom-half handlers

[Richard Henderson]

On 9/27/19 3:01 AM, Peter Maydell wrote:
>  (2) call the device's callback function directly when the
>      ptimer triggers from the QEMU timer expiry. But for
>      the case of "a call to ptimer_set_count() etc caused
>      the timer to trigger", don't call the callback, instead
>      return a boolean from those functions which tells the
>      caller that the timer triggered, and they need to deal
>      with it (by calling their callback function when they've
>      finished messing with the timer).
...
> I think overall I favour option 2, which is a bit more
> syntactically invasive in terms of changing API signatures etc,
> but semantically easier to reason about (because the
> callback-function in the device is still not called when
> the device might be partway through doing an update to
> the ptimer state that changes multiple parameters of the
> ptimer).
> 
> Is there another cleverer fix that I haven't thought of?

If "other things" are being changed along with ptimer_set_count, then is the
boolean result of ptimer_set_count necessarily still relevant after the "other
things"?

Can we record the set of things to be done within a
ptimer_transaction_{begin,commit}() pair and then invoke the callback (if
necessary) when committing?  Is it even easy to see the set of "other things"
that would need to be wrapped?

I think I need a bit of time understanding the use cases in hw/timer/ before
being able to suggest anything more definite...


r~