δΊ 2013-8-10 19:05, Alex Bligh ει:
Paolo,
On 9 Aug 2013, at 15:59, Paolo Bonzini wrote:
It's not papering over anything.
Timers right now are provided by the event loop. If you make
AioContexts have timers, you can have a new AioContext for the timers
that the event loop handles before your
--On 12 August 2013 14:53:06 +0800 Wenchao Xia xiaw...@linux.vnet.ibm.com
wrote:
1. Wrap TimerListGroup into a separate struct, leave all the
TimerListGroup functions in. This probably makes it easier if
(for instance) we decided to get rid of AioContexts entirely
and make them
Il 11/08/2013 10:29, Alex Bligh ha scritto:
Paolo,
--On 11 August 2013 09:53:38 +0200 Paolo Bonzini pbonz...@redhat.com
wrote:
There is actually a disadvantage of moving TimerListGroup to AioContext.
The disadvantage is that GSources can only work with millisecond
resolution. Thus you
On 12 Aug 2013, at 18:27, Paolo Bonzini wrote:
So let's keep the TimerListGroup for now.
OK - do you want me to wrap it in a struct? Other than that I think I've
done all the comments in v8. Happy to do that with v10 if there are
other comments on v9.
No, it's okay. Unless you want
Il 10/08/2013 13:05, Alex Bligh ha scritto:
Despite the fact we both dislike the name TimerListGroup, I
think the way to go here is (1). (2) does not really save lines
of code (certainly not compiled instructions) - it's main saving
is removing a pile of commenting from include/qemu/timer.h,
Paolo,
--On 11 August 2013 09:53:38 +0200 Paolo Bonzini pbonz...@redhat.com
wrote:
There is actually a disadvantage of moving TimerListGroup to AioContext.
The disadvantage is that GSources can only work with millisecond
resolution. Thus you would need anyway some special casing of the
Il 10/08/2013 05:27, liu ping fan ha scritto:
... except if we get rid of TimerListGroup completely and put it in
AioContext. To do so, we can have _two_ AioContexts in main-loop.c.
One is for the block layer, the other is only used for timers. Later we
Why can the AioContexts of block
Paolo,
On 9 Aug 2013, at 15:59, Paolo Bonzini wrote:
It's not papering over anything.
Timers right now are provided by the event loop. If you make
AioContexts have timers, you can have a new AioContext for the timers
that the event loop handles before your patches.
It's not related to
Il 08/08/2013 23:42, Alex Bligh ha scritto:
Add QEMUTimerListGroup and helper functions, to represent
a QEMUTimerList associated with each clock. Add a default
QEMUTimerListGroup representing the default timer lists
which are not associated with any other object (e.g.
an AioContext as added
Paolo,
diff --git a/include/qemu/timer.h b/include/qemu/timer.h
index 1baa0e2..3b46f60 100644
--- a/include/qemu/timer.h
+++ b/include/qemu/timer.h
@@ -52,8 +52,10 @@ typedef enum {
typedef struct QEMUClock QEMUClock;
typedef struct QEMUTimerList QEMUTimerList;
+typedef QEMUTimerList
Il 09/08/2013 16:27, Alex Bligh ha scritto:
Paolo,
diff --git a/include/qemu/timer.h b/include/qemu/timer.h
index 1baa0e2..3b46f60 100644
--- a/include/qemu/timer.h
+++ b/include/qemu/timer.h
@@ -52,8 +52,10 @@ typedef enum {
typedef struct QEMUClock QEMUClock;
typedef struct
On 9 Aug 2013, at 15:35, Paolo Bonzini wrote:
The point is that you can get rid altogether of TimerListGroup if you
just stick the array in the AioContext. There's no use in adding a
concept with an easy plan to delete it, only waiting for someone willing
to do the work. It is not related
On Fri, Aug 09, 2013 at 04:35:31PM +0200, Paolo Bonzini wrote:
Il 09/08/2013 16:27, Alex Bligh ha scritto:
Paolo,
diff --git a/include/qemu/timer.h b/include/qemu/timer.h
index 1baa0e2..3b46f60 100644
--- a/include/qemu/timer.h
+++ b/include/qemu/timer.h
@@ -52,8 +52,10 @@ typedef
Il 09/08/2013 17:09, Stefan Hajnoczi ha scritto:
Perhaps, but do we really need it to work outside AioContexts? Using a
second AioContext for bottom halves has been mentioned for a while. It
would fix issues where a bottom half runs spuriously before QEMU starts,
just because something uses
Il 09/08/2013 16:47, Alex Bligh ha scritto:
On 9 Aug 2013, at 15:35, Paolo Bonzini wrote:
The point is that you can get rid altogether of TimerListGroup if you
just stick the array in the AioContext. There's no use in adding a
concept with an easy plan to delete it, only waiting for
[...]
typedef struct QEMUClock QEMUClock;
typedef struct QEMUTimerList QEMUTimerList;
+typedef QEMUTimerList *QEMUTimerListGroup[QEMU_CLOCK_MAX];
Please wrap this in a struct for easier future extensibility.
I'm not a big fan of the TimerListGroup name, but I cannot think of
anything
Add QEMUTimerListGroup and helper functions, to represent
a QEMUTimerList associated with each clock. Add a default
QEMUTimerListGroup representing the default timer lists
which are not associated with any other object (e.g.
an AioContext as added by future patches).
Signed-off-by: Alex Bligh
17 matches
Mail list logo
