On 08.05.2017 10:42, Markus Armbruster wrote:
> "Daniel P. Berrange" <berra...@redhat.com> 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 <th...@redhat.com>
>>>> ---
>>>> 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).
Thomas
