On Fri, Jul 19, 2013 at 06:26:23PM +0100, Alex Bligh wrote:
> [ This is a patch for RFC purposes only. It is compile tested on Linux x86_64
> only
> and passes make check (or rather did before make check started dying in the
> boot order test - different bug). I'd like to know whether I'm going in
> the right direction ]
Looks promising.
> We no longer need alarm timers to trigger QEMUTimer as we'll be polling
> them in aio_poll.
>
> Remove static declaration from qemu_new_clock and introduce qemu_free_clock.
>
> Maintain a list of QEMUClocks.
>
> Introduce qemu_clock_deadline_ns and qemu_clock_deadine_all_ns which
> calculate how
> long aio_poll etc. should wait, plus (for the time being) a conversion to
> milliseconds.
>
> Make qemu_run_timers return a bool to indicate progress.
>
> Add QEMUClock to AioContext.
>
> Run timers attached to clock in aio_poll
Too many logical changes for a single patch :). Please split this into
a series.
> @@ -52,6 +44,8 @@ struct QEMUClock {
>
> int type;
> bool enabled;
> +
> + QLIST_ENTRY(QEMUClock) list;
Please avoid global state. AioContext should be usable from multiple
threads, this list would require synchronization.
main-loop.c should call functions to run timers and calculate the
nearest deadline on vm_clock/host_clock/rt_clock. It knows about them,
they are defined in <qemu/timer.h>.
That way no list is needed.
