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
