From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=52574 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PFliM-0004U4-Lm for qemu-devel@nongnu.org; Tue, 09 Nov 2010 05:46:11 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PFliL-0002Kq-Bt for qemu-devel@nongnu.org; Tue, 09 Nov 2010 05:46:10 -0500 Received: from mx1.redhat.com ([209.132.183.28]:60627) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PFliL-0002KS-4n for qemu-devel@nongnu.org; Tue, 09 Nov 2010 05:46:09 -0500 Date: Tue, 9 Nov 2010 16:15:52 +0530 From: Amit Shah Subject: Re: [Qemu-devel] Re: [RFC][RESEND][PATCH v1 02/15] virtproxy: qemu-vp, standalone daemon skeleton Message-ID: <20101109104552.GA12647@amit-laptop.redhat.com> References: <1288798090-7127-1-git-send-email-mdroth@linux.vnet.ibm.com> <1288798090-7127-3-git-send-email-mdroth@linux.vnet.ibm.com> <1288824456.2846.15.camel@aglitke> <4CD2BBBA.3070002@linux.vnet.ibm.com> <1288963950.2055.3.camel@aglitke> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1288963950.2055.3.camel@aglitke> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Adam Litke Cc: abeekhof@redhat.com, aliguori@linux.vnet.ibm.com, agl@linux.vnet.ibm.com, Michael Roth , qemu-devel@nongnu.org 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