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

[Michael Roth <mdroth@linux.vnet.ibm.com>]

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