[Qemu-devel] Re: [RFC][PATCH v7 01/16] Move code related to fd handlers into utility functions

[Michael Roth]

On 03/09/2011 08:38 AM, Paolo Bonzini wrote:
> On 03/09/2011 03:11 PM, Michael Roth wrote:
> > In the context of virtagent I would agree. The only complication there
> > being that a large part of the event-driven code (the async read/write
> > handlers for instance) is shared between virtagent and the host.
>
> What exactly? The dependencies in 16/16 give:
>
> qemu-tool.o qemu-error.o qemu-sockets.c $(oslib-obj-y) $(trace-obj-y)
> $(block-obj-y) $(qobject-obj-y) $(version-obj-y) qemu-timer-common.o
> qemu-timer.o

These objs: virtagent.o virtagent-server.o virtagent-common.o 
virtagent-transport.o virtagent-manager.o

Are shared by qemu and qemu-va. virtagent.o uses the common timer 
infrastructure introduced in patch 3, and 
virtagent-transport/virtagent-common use the iohandler stuff from patch 1/2.

On the host, qemu's event loop drives them, and on the guest, qemu-va's 
event loop drives them.

Not sure what level of sharing we can maintain with 2 different event 
loops. I'm sure it's doable, just not sure what it would end up looking 
like.

I should note that initially all the qemu_set_fd_handler() stuff was 
wrapped to provide compatibility between separate event loop 
implementations in qemu/qemu-va. Sharing the event loop code was a 
widely-held consensus from earlier reviews. I'm not sure glib is so nice 
that it's worth back-peddling on that. And if we do eventually make 
qemu's event loop glib-based, consumers of the common code here would 
get migrated over for free.

> Compared to other tools, only qemu-sockets.c is added (and timers);
> overall it is quite self contained and interfaces well with glib's
> GIOChannels, which provide qemu_set_fd_handler-equivalent functionality.
>
> In addition, qemu iohandlers have a lot of unwritten assumptions, for
> example on Win32 they only work with sockets and not other kinds of file
> descriptors.

Hmm, that could be a problem... It seems like a more general one though, 
that might benefit consumers other than virtagent. So if this is 
addressed at some point, consumers of the common infrastructure proposed 
here would all benefit.

> Paolo