From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MA0IC-0006QX-CI for qemu-devel@nongnu.org; Fri, 29 May 2009 07:30:32 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MA0I6-0006MS-W7 for qemu-devel@nongnu.org; Fri, 29 May 2009 07:30:31 -0400 Received: from [199.232.76.173] (port=39546 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MA0I6-0006MG-Lb for qemu-devel@nongnu.org; Fri, 29 May 2009 07:30:26 -0400 Received: from mx2.redhat.com ([66.187.237.31]:34016) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MA0I6-0006Nz-7w for qemu-devel@nongnu.org; Fri, 29 May 2009 07:30:26 -0400 Date: Fri, 29 May 2009 08:35:56 -0300 From: Glauber Costa Message-ID: <20090529113556.GH30777@poweredge.glommer> References: <1243551838-1980-1-git-send-email-glommer@redhat.com> <4A1F77C0.9050407@codemonkey.ws> <4A1FA616.7040402@siemens.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A1FA616.7040402@siemens.com> Subject: [Qemu-devel] Re: [PATCH] remove pieces of source code List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: aliguori@us.ibm.com, qemu-devel@nongnu.org On Fri, May 29, 2009 at 11:08:38AM +0200, Jan Kiszka wrote: > 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: > > > > o Since it's enabled by default, it forces the default build to support > > < 4GB of guest memory > > Making -no-kqemu the default appears as a reasonable first step then - > to kill those silly "Could not open '/dev/kqemu'" warnings) and also to > collect complains like: "What the heck happened to kqemu?" We have at least one _stable_ release at this point that includes kqemu. So why not just remove it for the next one? > > > o There is no alternative for non-Linux users and folks with non-VT/SVM > > hardware > > The non-HVM argument will become widely irrelevant (for desktops) very > soon. The non-Linux issue will likely persist - unless someone feels so > much pain to write some KVM for those platforms. But as long as there is > a kqemu version that builds and works for them, I think we should keep > QEMU's support. But it should no longer be a first-class citizen: off by > default, factored out into more hooks, maybe even de-optimized where it > blocks development or increases the maintenance effort of QEMU. Any change we make to decrease its citizenship status will likely break it very fast. Reality is noone here really understands it.