From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MA0Eq-0003sY-QD for qemu-devel@nongnu.org; Fri, 29 May 2009 07:27:04 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MA0En-0003ot-2y for qemu-devel@nongnu.org; Fri, 29 May 2009 07:27:04 -0400 Received: from [199.232.76.173] (port=35186 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MA0Em-0003oO-Lc for qemu-devel@nongnu.org; Fri, 29 May 2009 07:27:00 -0400 Received: from mx2.redhat.com ([66.187.237.31]:44300) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MA0Em-0005Fs-7W for qemu-devel@nongnu.org; Fri, 29 May 2009 07:27:00 -0400 Date: Fri, 29 May 2009 08:32:30 -0300 From: Glauber Costa Subject: Re: [Qemu-devel] [PATCH] remove pieces of source code Message-ID: <20090529113230.GG30777@poweredge.glommer> References: <1243551838-1980-1-git-send-email-glommer@redhat.com> <4A1F77C0.9050407@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A1F77C0.9050407@codemonkey.ws> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: aliguori@us.ibm.com, qemu-devel@nongnu.org On Fri, May 29, 2009 at 12:50:56AM -0500, Anthony Liguori wrote: > Glauber Costa wrote: > > Have you ever seen a girl so beautiful that you, geeky, > > think: "I'll never stand a chance"? > > > > But sometimes, you decide to make your move anyway. There's > > always the chance that in that very day she'll be specially > > in good mood, and you'll get what you want. > > > > With the exception of the fact that qemu is not a girl, > > that's more or less what I'm trying to do here: Hopefully, > > nobody will notice what I'm trying to do, and will commmit it. > > Later, when realizing, it will be too late. Victory will be mine. > > > > Or maybe people will even agree. For that, I'll try briefly > > to arguee my point, without disclosing to much, avoiding > > jeopardizing the strategy I explained above: > > > > This patch removes a piece of code that is unmaintaned, > > that does not receive an update for years, > > that get bug reports on the list that nobody fixes, because > > nobody really understands, > > that places some artificial constraints on other subsystems > > > > Signed-off-by: Glauber Costa > Let's actually build a proper case instead of closing our eyes and > hitting enter. Here are the downsides of kqemu I know of: Okay... you do realize I was kidding, and I never really expected this to happen at first, right? ;-) > > o Since it's enabled by default, it forces the default build to support > < 4GB of guest memory > o It attempts to use /dev/shm for guest memory which means a special > option is needed in the default build to use more than 1/2 of host ram size > o It touches an awful lot of places in QEMU > o Some of the BIOS changes are particularly nasty and will prevent > having a unified BIOS between QEMU and Bochs > o The kernel bits will never go upstream for Linux > o No one actively supports kqemu in upstream QEMU > > That said, here are the arguments for keeping kqemu > > o Even though it's unmaintained, it seems to work for people But traffic in the mailing list indicates that it is less and less the case. And more importantly: As it bitrots, nobody fixes it. so... > o There is no alternative for non-Linux users and folks with non-VT/SVM > hardware Sure, but I don't think kqemu is such an alternative. ;-)