Re: [Qemu-devel] Re: [PATCH] remove pieces of source code

[Stefan Weil <weil@mail.berlios.de>]

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 <glommer@redhat.com
>>>>       
>>>>         
>>> 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