On 02.05.2017 13:59, Daniel P. Berrange wrote: > On Tue, May 02, 2017 at 01:26:17PM +0200, Thomas Huth wrote: >> 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. > > The issue is that we have mutually exclusive requirements here. For a > straightforward, easy to understand CLI, things like "--enable-kvm" are > much quicker to discover & understand than "-machine accel=kvm". The > latter gives much more flexibility since it can set all the other opts, > but most of those are rarely used by people who are invoking QEMU > manually/directly. We need the things like -machine for libvirt and > similar, but they are not end user friendly. Killing all the shortcuts > like --enable-kvm would cut down the args we expose, but forcing users > onto more complex syntax for args like -machine is not improving their > lives in general if they don't need that extra flexibility.
Theoretically yes, but in this case we also have the "-accel kvm" option which is IMHO also straighforward and easy to understand, and even shorter than "-enable-kvm". If you look at my patch, I did *not* want to force the normal users to use "-machine accel=kvm" here, so I don't see the point of your argument here. Thomas
