From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1M9y97-0004to-ML for qemu-devel@nongnu.org; Fri, 29 May 2009 05:13:01 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1M9y93-0004sF-QB for qemu-devel@nongnu.org; Fri, 29 May 2009 05:13:01 -0400 Received: from [199.232.76.173] (port=55958 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1M9y93-0004sC-NZ for qemu-devel@nongnu.org; Fri, 29 May 2009 05:12:57 -0400 Received: from mail-qy0-f123.google.com ([209.85.221.123]:57046) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1M9y93-0002zK-7X for qemu-devel@nongnu.org; Fri, 29 May 2009 05:12:57 -0400 Received: by qyk29 with SMTP id 29so6531075qyk.4 for ; Fri, 29 May 2009 02:12:56 -0700 (PDT) Message-ID: <4A1FA714.9030504@codemonkey.ws> Date: Fri, 29 May 2009 04:12:52 -0500 From: Anthony Liguori MIME-Version: 1.0 References: <1243551838-1980-1-git-send-email-glommer@redhat.com> <4A1F77C0.9050407@codemonkey.ws> <4A1FA616.7040402@siemens.com> In-Reply-To: <4A1FA616.7040402@siemens.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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: Glauber Costa , qemu-devel@nongnu.org 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?" > Yes. Note that -no-kqemu doesn't fix the above complaint but it fixes the following one. So unless there are major objections, I'd like to make -no-kqemu the default for 0.11. We can then discuss whether to make kqemu deprecated and scheduled for removal in 0.12. >> 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 >> > > We did some work on it a few months ago, trying to enhance its support > for segmented guests. It turned out to require unreasonable effort and > would still perform not significantly better than plain qemu in this > context (and our customer dropped the idea to support legacy systems > anyway). The results are a few low-level fixes and enhancements (that I > still want to post once cleaned up) and the confirmation of what is > likely already clear to people who had a look at the kernel bits: They > are almost unmaintainable and can cause severe headache when trying to > understand them. > > >> That said, here are the arguments for keeping kqemu >> >> o Even though it's unmaintained, it seems to work for people >> > > At some point, I bet, at least the Linux bindings will break, and no one > will be interested or able to fix that anymore. Same may happen to other > platforms (doesn't Windows 7 come with a new driver model?). > > >> 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. > 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. Regards, Anthony Liguori > Jan > >