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

[Adam Litke]

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.

-- 
Thanks,
Adam