On 02/05/2017 17:53, Thomas Huth wrote: >>> >>> 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?
Yes, having a list of accelerators would be useful. For example: -accel tcg[,threads=on|off] .... -accel kvm -accel hax -accel qtest >> 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? No, updating the documentation is pointless if you don't improve it at the same time. I don't like writing it so often, especially to someone who is a relatively experienced contributor, but the common word in all these reviews is "pointless". What is the *purpose* of this work? I think a valid purpose would be to improve documentation, for example. Another would be to consolidate non-QemuOpts command-line options. For this, some options that are entirely internal provide interesting grounds for improvement. For example, "-qtest" and "qtest-log" could be consolidated in "-qtest [chardev=]chardev,log=file". Paolo