Re: [Qemu-devel] Re: [RFC][RESEND][PATCH v1 02/15] virtproxy: qemu-vp, standalone daemon skeleton

[Amit Shah <amit.shah@redhat.com>]

On (Fri) Nov 05 2010 [08:32:30], Adam Litke wrote:
> On Thu, 2010-11-04 at 08:57 -0500, Michael Roth wrote:
> > > This resembles vl.c's main_loop_wait() but I can see why you might want
> > > your own.  There is opportunity for sharing the select logic and ioh
> > > callbacks but I think that could be addressed later.
> > >
> > 
> > Yup these are all basically copy/pastes from vl.c. It feels a bit dirty, 
> > but I modeled things after the other qemu tools like qemu-nbd/qemu-io, 
> > which don't link against vl.c (and adding a target for tools to do so 
> > looks like it'd be a bit hairy since vl.c touches basically everything).
> 
> > It might still make sense to share things like structs...but the ones 
> > I'm stealing here are specific to reproducing the main_loop_wait logic. 
> > So I guess the real question is whether main_loop_wait and friends make 
> > sense to expose as a utility function of some sort, and virtproxy seems 
> > to be the only use case so far.
> 
> You make a fair point about following precedent, but the thought of
> dual-maintaining code into the future is not that appealing.  I guess we
> could benefit from other voices on this topic.

I agree we should share the code -- I have some patches for qemu
chardevs to behave reasonably when buffers are full (so we don't see
guest hangs).  You'll benefit as soon as that work enters git.

		Amit