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
