On 02.05.2017 17:09, Paolo Bonzini wrote: > > > On 02/05/2017 17:01, Markus Armbruster wrote: >>> But I really, really see no point in removing --enable-kvm. It costs >>> perhaps 10 lines of code that has pretty much no ramifications elsewhere >>> in the code. If anything I'd expect "-machine accel" to disappear >>> before, if ever (in favor of multiple "-accel" options, e.g. "-machine >>> accel=kvm:tcg" can become "-accel kvm -accel tcg". >> I basically agree, except I wouldn't say "no point", but "doesn't buy us >> enough to justify inconveniencing users". >> >> What we've done before for options that have become unloved, but not >> harmful, is remove them just from documentation. Grep qemu-options.hx >> for "HXCOMM Deprecated". Let's do that for --enable-kvm and similarly >> weird sugared options. > > Except that this provides no easily greppable way to find how to enable > KVM, as things stand.
Should we then improve the description of the -accel parameter? > So the first lesson should be "no deprecation > without documentation" (any reference to 18th century political slogans > is purely coincidential :)). Would you accept my patch if I'd remove the hunks for vl.c, i.e. a patch that just updates the documentation? Thomas PS: Thinking about all of this again, I think the thing that bugs me most is that we now have a brand new "-enable-hax" option, too, but no "-enable-xen" option ... that's just inconsistent. What do you think about removing the "-enable-hax" option again - there should only be very few users for this option so far, so the impact should be low. HAX users could simply use the "-accel hax" instead...
