|
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 08:11:33 -0600 |
User-agent: | Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 |
On 03/09/2011 07:58 AM, Paolo Bonzini wrote:
On 03/07/2011 09:10 PM, Michael Roth wrote:This allows us to implement an i/o loop outside of vl.c that can interact with objects that use qemu_set_fd_handler()I must say I really dislike the patches 1..3. It's _really_ getting the QEMU NIH worse. While it is not really possible to get a new shiny mainloop infrastructure in QEMU like snapping fingers (and I'm not sure the glib mainloop will ever happen there), there is no reason not to adopt glib's infrastructure in virtagent. While cooperation between QEMU and virtagent is close, it is IMHO a substantially separate project that can afford starting from a clean slate. If anybody disagrees, I'd be happy to hear their opinion anyway! I'm sorry I'm saying this only now and I've been ignoring this series until v7.
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. Possibility this could be worked around with a set of wrappers..but it's hard to say.
But more importantly, I wouldn't think of these changes as being specific to virtagent though. Currently we have a lot of qemu tools that stub out portions of the block code they pull in (qemu_set_fd_handler and whatnot). I think it might be beneficial to future tools/test utilities that they actually be able to drive things like aio and timer events. We just keep stubbing more and more things out in these cases, which I would argue is even worse because it can place artificial constraints on how code is written that happens to get used by such tools.
Paolo
[Prev in Thread] | Current Thread | [Next in Thread] |