Re: [Qemu-devel] [PATCH] Mark legacy option '-no-kvm' as deprecated

[Daniel P. Berrange]

On Mon, May 08, 2017 at 11:14:00AM +0200, Thomas Huth wrote:
> On 08.05.2017 10:42, Markus Armbruster wrote:
> > "Daniel P. Berrange" <address@hidden> writes:
> > 
> >> On Fri, May 05, 2017 at 03:48:37PM +0100, Stefan Hajnoczi wrote:
> >>> On Tue, May 02, 2017 at 01:54:22PM +0200, Thomas Huth wrote:
> >>>> '-no-kvm' was just a legacy convenience option for the users of
> >>>> qemu-kvm, it never made sense in the normal QEMU tree since TCG is
> >>>> the default here anyway. The option has also never been specified
> >>>> in the QEMU docs and in the '--help' list, so likely hardly anybody
> >>>> knows about this option at all. I think we could get rid of this
> >>>> without bothering anybody nowadays, but just in case, let's print
> >>>> out a warning for a couple of releases first.
> >>>>
> >>>> Signed-off-by: Thomas Huth <address@hidden>
> >>>> ---
> >>>>  vl.c | 4 +++-
> >>>>  1 file changed, 3 insertions(+), 1 deletion(-)
> >>>>
> >>>> diff --git a/vl.c b/vl.c
> >>>> index d5ec87e..2d44621 100644
> >>>> --- a/vl.c
> >>>> +++ b/vl.c
> >>>> @@ -3709,7 +3709,9 @@ int main(int argc, char **argv, char **envp)
> >>>>                      exit(1);
> >>>>                  }
> >>>>                  break;
> >>>> -             case QEMU_OPTION_no_kvm:
> >>>> +            case QEMU_OPTION_no_kvm:
> >>>> +                error_report("'-no-kvm' is depreacted, please use "
> >>>
> >>> s/depreacted/deprecated/
> >>
> >> Should we have an dedicated  'error_deprecated(oldfeat, newfeat)' method
> >> that prints a standardized message, as well as a -no-deprecated flag that
> > 
> > I hate flags starting with "no".  What about something like
> > --suppress-deprecation-warnings?
> > 
> >> turns off all the deprecation warnings. There's nothing more annoying than
> >> an application that insists on spewing warnings to stdout that you know
> >> about, but aren't in a position to address any time soon.
> > 
> > If we do that, we should consider having the warnings tell users how to
> > suppress them, say "You can suppress this warning with
> > --suppress-deprecation-warnings".
> 
> IMHO we should not add such a flag. Otherwise people will simply always
> turn it on and not only ignore this warning, but also all other
> warnings. I think these warnings *have* to be annoying to make sure that
> people change their scripts.
> (And if they "aren't in a position to address any time soon", they
> likely also aren't in a position to add a
> "--suppress-deprecation-warnings" parameter to their scripts either).

That isn't really true. Adding a --suppress-deprecation-warnings flag does
not change semantics of either QEMU, or the mgmt app and so would not have
any coding or testing burden.  Rewriting the mgmt app code to generate the
QEMU command line in a different way has significant overhead in both code
and testing work, as well as potential to introduce semantic bugs.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|