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
