Jan,
--On 26 July 2013 12:05:06 +0200 Jan Kiszka <jan.kis...@siemens.com> wrote:
I would happily at a QEMUClock of each type to AioContext. They are
after
all pretty lightweight.
What's the point of adding tones of QEMUClock instances? Considering
proper abstraction, how are they different for each AioContext? Will
they run against different clock sources, start/stop at different times?
If the answer is "they have different timer list", then fix this
incorrect abstraction.
Even if I fix the abstraction, there is a question of whether it is
necessary to have more than one timer list per AioContext, because
the timer list is fundamentally per clock-source.
So far. Once we support different handler thread for timers, there will
be more lists than clock sources.
Right.
So my PATCHv4 series breaks up QEMUClock into QEMUClock and QEMUTimerList:
http://lists.nongnu.org/archive/html/qemu-devel/2013-07/msg04887.html
Unfortunately I've needed to keep qemu_new_timer AND
qemu_new_timer_timerlist about to avoid horrendous git stats
due to the consequent API changes (I did it, but you don't want to see
it), and these have several variants. Apart from that it wasn't too bad.
--
Alex Bligh
