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~