[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] Re: [PATCH] remove pieces of source code
From: |
Stefan Weil |
Subject: |
Re: [Qemu-devel] Re: [PATCH] remove pieces of source code |
Date: |
Fri, 29 May 2009 11:35:04 +0200 |
User-agent: |
Mozilla-Thunderbird 2.0.0.19 (X11/20090103) |
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 <address@hidden
>>>>
>>>>
>>> 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
Re: [Qemu-devel] [PATCH] remove pieces of source code, Glauber Costa, 2009/05/29