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~
