qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Markus Armbruster
Subject: Re: [Qemu-devel] [PATCH] Mark legacy option '-no-kvm' as deprecated
Date: Mon, 08 May 2017 10:42:18 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux)

"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".



reply via email to

[Prev in Thread] Current Thread [Next in Thread]