From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MBaIt-00080S-QC for qemu-devel@nongnu.org; Tue, 02 Jun 2009 16:09:47 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MBaIp-0007x5-Cx for qemu-devel@nongnu.org; Tue, 02 Jun 2009 16:09:47 -0400 Received: from [199.232.76.173] (port=32947 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MBaIp-0007ws-6Y for qemu-devel@nongnu.org; Tue, 02 Jun 2009 16:09:43 -0400 Received: from mtaout02-winn.ispmail.ntl.com ([81.103.221.48]:32216) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MBaIo-0000Ie-JJ for qemu-devel@nongnu.org; Tue, 02 Jun 2009 16:09:43 -0400 Received: from aamtaout02-winn.ispmail.ntl.com ([81.103.221.35]) by mtaout02-winn.ispmail.ntl.com (InterMail vM.7.08.04.00 201-2186-134-20080326) with ESMTP id <20090602200938.XMWE6611.mtaout02-winn.ispmail.ntl.com@aamtaout02-winn.ispmail.ntl.com> for ; Tue, 2 Jun 2009 21:09:38 +0100 Received: from miranda.arrow ([213.107.24.213]) by aamtaout02-winn.ispmail.ntl.com (InterMail vG.2.02.00.01 201-2161-120-102-20060912) with ESMTP id <20090602200938.UETV21638.aamtaout02-winn.ispmail.ntl.com@miranda.arrow> for ; Tue, 2 Jun 2009 21:09:38 +0100 Received: from sdb by miranda.arrow with local (Exim 4.63) (envelope-from ) id 1MBaIh-0004Dp-Sr for qemu-devel@nongnu.org; Tue, 02 Jun 2009 21:09:35 +0100 Date: Tue, 2 Jun 2009 21:09:35 +0100 From: Stuart Brady Subject: Re: [Qemu-devel] Re: [PATCH] remove pieces of source code Message-ID: <20090602200935.GA16182@miranda.arrow> References: <1243551838-1980-1-git-send-email-glommer@redhat.com> <4A1F77C0.9050407@codemonkey.ws> <4A1FA616.7040402@siemens.com> <4A1FA714.9030504@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A1FA714.9030504@codemonkey.ws> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org On Fri, May 29, 2009 at 04:12:52AM -0500, Anthony Liguori wrote: > If we disable in configure, then we should remove it from the tree. The > feeling is that code that's disabled by default is too likely to bitrot. > > I think you've made a reasonable suggestion though. So unless there are > strong feelings otherwise, I think we should do -no-kqemu by default for > 0.11, see what the reaction is, then figure out whether we want to > deprecate/remove. One option that has not been suggested is building binaries both with and without kqemu enabled by default. This would allow limitations that are imposed by enabling kqemu to be avoided, but wouldn't help to avoid any limitations imposed by the mere existence of kqemu support in the code. It also gives the user an extra binary that they shouldn't really have to know or care about, and prevents any "what happened to kqemu?!" feedback from being received. However, as an intermediate step, perhaps it might be worth considering. Either way, kqemu will clearly disappear at some point, unless someone with the required knowledge, skill, time, interest and pervasiveness intervenes. Silly question, btw -- I've heard on several occasions that kqemu is not auditable. Is it even possible to produce a replacement with reasonable performance that *is* auditable? (Whilst I certainly have the interest, I'm not sure whether I possess a sufficient quantity of the other four required attributes to implement something like this for KVM, if such a thing is even possible.) Cheers, -- Stuart Brady