From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1M9yUc-0004ou-Of for qemu-devel@nongnu.org; Fri, 29 May 2009 05:35:14 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1M9yUY-0004nP-Sz for qemu-devel@nongnu.org; Fri, 29 May 2009 05:35:14 -0400 Received: from [199.232.76.173] (port=53762 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1M9yUY-0004nF-2K for qemu-devel@nongnu.org; Fri, 29 May 2009 05:35:10 -0400 Received: from moutng.kundenserver.de ([212.227.17.10]:61998) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1M9yUX-00047v-Ca for qemu-devel@nongnu.org; Fri, 29 May 2009 05:35:09 -0400 Message-ID: <4A1FAC48.7010309@mail.berlios.de> Date: Fri, 29 May 2009 11:35:04 +0200 From: Stefan Weil MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: [PATCH] remove pieces of source code References: <1243551838-1980-1-git-send-email-glommer@redhat.com> <4A1F77C0.9050407@codemonkey.ws> <4A1FA616.7040402@siemens.com> <4A1FA714.9030504@codemonkey.ws> In-Reply-To: <4A1FA714.9030504@codemonkey.ws> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: QEMU Developers Anthony Liguori schrieb: > 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 >> >> >> Default setting -no-kqemu is ok for all platforms without kqemu support or with working kvm support. For Win32, I prefer to have kqemu support enabled by default. Regards, Stefan Weil