On 02.05.2017 14:07, Thomas Huth wrote: > 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.
Apart from that, we never use "-enable-xxx" for any other convenience option, e.g. we do not use "-enable-usb", but just "-usb". So for a real convenience option to enable KVM, the option should have been simply named "-kvm" instead. That "-enable-xxx" stuff is just bad and IMHO does not really fit into the QEMU world. Thomas
