[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RFC 3/4] ptimer: Provide new transaction-based API
From: |
Richard Henderson |
Subject: |
Re: [RFC 3/4] ptimer: Provide new transaction-based API |
Date: |
Mon, 7 Oct 2019 09:30:27 -0400 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 |
On 10/4/19 4:48 AM, Peter Maydell wrote:
> Provide the new transaction-based API. If a ptimer is created
> using ptimer_init() rather than ptimer_init_with_bh(), then
> instead of providing a QEMUBH, it provides a pointer to the
> callback function directly, and has opted into the transaction
> API. All calls to functions which modify ptimer state:
> - ptimer_set_period()
> - ptimer_set_freq()
> - ptimer_set_limit()
> - ptimer_set_count()
> - ptimer_run()
> - ptimer_stop()
> must be between matched calls to ptimer_transaction_begin()
> and ptimer_transaction_commit(). When ptimer_transaction_commit()
> is called it will evaluate the state of the timer after all the
> changes in the transaction, and call the callback if necessary.
>
> In the old API the individual update functions generally would
> call ptimer_trigger() immediately, which would schedule the QEMUBH.
> In the new API the update functions will instead defer the
> "set s->next_event and call ptimer_reload()" work to
> ptimer_transaction_commit().
>
> We use assertions to check that:
> * the functions modifying ptimer state are not called outside
> a transaction block
> * ptimer_transaction_begin() and _commit() calls are paired
> * the transaction API is not used with a QEMUBH ptimer
>
> There is some slight repetition of code:
> * most of the set functions have similar looking "if s->bh
> call ptimer_reload, otherwise set s->need_reload" code
> * ptimer_init() and ptimer_init_with_bh() have similar code
> We deliberately don't try to avoid this repetition, because
> it will all be deleted when the QEMUBH version of the API
> is removed.
>
> Signed-off-by: Peter Maydell <address@hidden>
With the need_reload fix, as you noted, and one other nit,
Reviewed-by: Richard Henderson <address@hidden>
> +/**
> + * ptimer_init - Allocate and return a new ptimer
> + * @callback: function to call on ptimer expiry
> + * @callback_data: opaque pointer passed to @callback
Comment mismatch with...
> +ptimer_state *ptimer_init(ptimer_cb callback,
> + void *callback_opaque,
the declaration and all the uses. Either name works for me.
r~
- [RFC 0/4] transaction-based ptimer API, Peter Maydell, 2019/10/04
- [RFC 1/4] hw/timer/arm_timer: Add trace events, Peter Maydell, 2019/10/04
- [RFC 2/4] ptimer: Rename ptimer_init() to ptimer_init_with_bh(), Peter Maydell, 2019/10/04
- [RFC 4/4] hw/timer/arm_timer.c: Switch to transaction-based ptimer API, Peter Maydell, 2019/10/04
- [RFC 3/4] ptimer: Provide new transaction-based API, Peter Maydell, 2019/10/04
- Re: [RFC 0/4] transaction-based ptimer API, Paolo Bonzini, 2019/10/04