Re: [Qemu-devel] [PATCH] Deprecate '-enable-kvm' and '-enable-hax' in favour of '-accel'

[Thomas Huth]

On 02.05.2017 12:48, Christian Borntraeger wrote:
> On 05/02/2017 12:37 PM, Thomas Huth wrote:
>> On 02.05.2017 12:32, Christian Borntraeger wrote:
>>> On 05/02/2017 12:06 PM, Thomas Huth wrote:
>>>> The '-enable-...' option do not make too much sense: They do not
>>>> allow additional parameters, using '-accel xxx' is shorter than
>>>> '-enable-xxx' and we're also inconsistent here, since there is
>>>> no '-enable-xen' option available. So let's try to convince the
>>>> users to use '-accel xxx' instead.
>>>
>>> google has 36000 hits for "--enable-kvm" and 18000 hits for "--accel kvm"
>>> So I assume this will affect a lot of setups for only a very small benefit.
>>
>> I'm aware of the fact that likely a lot of users are still using
>> -enable-kvm, and I did not mean that we should remove it soon yet. But
>> IMHO we should start now to inform the users that they should slowly
>> switch to the better option "-accel" instead, so that we could maybe
>> remove this "-enable-xxx" stuff sometime in the distant future (let's
>> say QEMU v4.0?).
> 
> I come from the Linux side, where "breaking a working setup" will result in
> an angry Linus.

IMHO that's a good approach, but I think it should primarily applied for
the interfaces that are designed as "API" to other software layers, i.e.
things like QMP and the "-machine" parameter.
"-enable-kvm" is in my eyes rather a "syntactic sugar" convenience
option, so I'd not apply this rule to this option.

> We certainly have not such strict rules here and we could
> base the decision on the question "how expensive is the maintenance
> of this option?". I think marking it as "legacy option" is fine, but I doubt
> that removing it will make qemu maintenance cheaper.

Likely not. Actually, I have another point of view in mind here: You
have to consider that QEMU has a *lot* of options, and I think this is
very confusing for the users, especially the new ones. If we always
provide two or three ways to achieve a goal, especially in an
inconsistent way like we do it here, we likely rather create frustration
than joy for the normal users. Providing a clean, straightforward CLI
interface one day could help to improve the user experience quite a bit.

> So my preferred variant is
> - have it marked in the docs as "legacy"
> - no error_report as it might break some setups (since error_report might 
> write
> to the monitor)
> - never remove the option unless it turns out to be a burden
> 
> But its certainly not my call to make.

Paolo, since you're the KVM / main loop maintainer, what's your opinion
here?

 Thomas