On 02.05.2017 12:21, Daniel P. Berrange wrote: > On Tue, May 02, 2017 at 12:06:40PM +0200, 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. > > What is our general approach to deciding which of our "legacy" parameters > are merely syntactic sugar for other parameters, vs stuff we want to > deprecate & eventually remove ?
I'd say if the parameters can help to specify something in a short way, then it's nice-to-have syntactic sugar. Otherwise, it's just legacy cruft which should be removed one day. For the accelerator options, we've got now three (!) ways to specify them: 1) -machine accel=xxx (which is the way we use it internally, thus we should keep it) 2) -enable-xxx 3) -accel xxx -accel xxx makes sense as syntactic sugar since it helps to keep the command line short, but I fail to see the reason for the inconsistent and inflexible "-enable-xxx" here, so I'd like to suggest to mark it as deprecated so we could remove it one day (it's likely in use in the wild, so maybe remove it in v4.0.0 in a couple of years?). Thomas