On 07/06/2018 13:10, Thomas Huth wrote: > On 07.06.2018 13:07, Paolo Bonzini wrote: >> On 07/06/2018 09:50, Thomas Huth wrote: >>> >>>> There's no real need to kill off '?', unless it gets in the way of >>>> steering people towards 'help'. We should steer them toward 'help', >>>> because '?' is a trap for insufficiently sophisticated users of >>>> shell[*]. >>> ... and I agree with your points here. >>> >>> => I think we need a second list of deprecated feature (maybe we should >>> call them "legacy features" instead of "deprecated"?), i.e. a list of >>> features which we don't recommend for new code / scripts anymore, but >>> which we do not intend to remove via our official deprecation policy any >>> time soon. Things like "--enable-kvm" / "-no-kvm" or maybe even "-net" >>> go into the same category. >> >> Yes, "-net" definitely goes there. >> >>> If you agree, I can try to come up with a patch (should the list go into >>> qemu-doc.texi or a separate document in the the documentation folder?). >> >> I think it should go in docs/devel. > > I currently rather tend to put it into a new appendix in qemu-doc.texi, > since this is useful information for the normal users, too. Or how shall > we communicate this to the users that the old options that they are used > to are still there, but should not be used for new scripts anymore?
I think we should tell them directly in the text for things like "-net". The new document would put things together and be mostly about command-line (anti)patterns. As to "-enable-kvm", I don't see anything wrong with users using it, or even with occasionally adding more options like it. However, we should warn developers that such simple options should be syntactic sugar for a structured (i.e. QemuOpts-based) option like "-accel", and that it should only be done for similarity with existing options. Basically the same reason why new options have both "?" and "help", even though "?" is disliked. Paolo