From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:56488) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1d7f9u-0002ex-VF for qemu-devel@nongnu.org; Mon, 08 May 2017 05:40:52 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1d7f9r-0003n9-KV for qemu-devel@nongnu.org; Mon, 08 May 2017 05:40:50 -0400 Received: from mx1.redhat.com ([209.132.183.28]:33594) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1d7f9r-0003li-Bf for qemu-devel@nongnu.org; Mon, 08 May 2017 05:40:47 -0400 Date: Mon, 8 May 2017 10:40:39 +0100 From: "Daniel P. Berrange" Message-ID: <20170508094039.GG18871@redhat.com> Reply-To: "Daniel P. Berrange" References: <1493726062-31743-1-git-send-email-thuth@redhat.com> <20170505144837.GB14316@stefanha-x1.localdomain> <20170505145049.GM12773@redhat.com> <871srz7n9x.fsf@dusky.pond.sub.org> <5c08c6b2-f82f-8e75-622e-0b229971cd8b@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <5c08c6b2-f82f-8e75-622e-0b229971cd8b@redhat.com> Subject: Re: [Qemu-devel] [PATCH] Mark legacy option '-no-kvm' as deprecated List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Thomas Huth Cc: Markus Armbruster , Stefan Hajnoczi , Paolo Bonzini , qemu-devel@nongnu.org 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" 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 > >>>> --- > >>>> 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 :|