[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Michael Roth
Subject: [Qemu-devel] Re: [RFC][PATCH v7 01/16] Move code related to fd handlers into utility functions
Date: Wed, 09 Mar 2011 09:01:46 -0600
User-agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv: Gecko/20110303 Thunderbird/3.1.9

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

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

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]