From: Markus Armbruster <armbru@redhat.com>
To: Kevin Wolf <kwolf@redhat.com>
Cc: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>,
qemu-block@nongnu.org, libvir-list@redhat.com,
qemu-devel@nongnu.org, mreitz@redhat.com, den@openvz.org,
John Snow <jsnow@redhat.com>
Subject: Re: [Qemu-devel] [PATCH 2/2] qapi: deprecate implicit filters
Date: Fri, 16 Aug 2019 14:33:26 +0200 [thread overview]
Message-ID: <87d0h5p9wp.fsf@dusky.pond.sub.org> (raw)
In-Reply-To: <20190816082013.GB5014@localhost.localdomain> (Kevin Wolf's message of "Fri, 16 Aug 2019 10:20:13 +0200")
Kevin Wolf <kwolf@redhat.com> writes:
> Am 15.08.2019 um 21:24 hat Markus Armbruster geschrieben:
[...]
>> Let's assume all libvirt ever does with deprecation notices is logging
>> them. Would that solve the problem of reliably alerting libvirt
>> developers to deprecation issues? Nope. But it could help
>> occasionally.
>
> I'm not saying that deprecation notices would hurt, just that they
> probably won't solve problem alone.
No argument.
> Crashing if --future is given and logging otherwise seems reasonable
> enough to me. Whether we need to wire up a new deprecation mechanism in
> QMP for the logging or if we can just keep printing to stderr is
> debatable. stderr already ends up in a log file, a QMP extension would
> require new libvirt code. If libvirt would log deprecation notices more
> prominently, or use the information for tainting or any other kind of
> processing, a dedicated QMP mechanism could be justified.
I'd like to start with two tasks:
* A CLI option to configure what to do on use of a deprecated feature.
We currently warn. We want to be able to crash instead. Silencing
the warnings might be useful. Turning them into errors might be
useful.
The existing ad hoc warnings need to be replaced by a call of a common
function that implements the configurable behavior.
* QAPI feature flag "deprecated", for introspectable deprecation, and
without ad hoc code.
Then see whether our users need more.
next prev parent reply other threads:[~2019-08-16 12:34 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-14 10:07 [Qemu-devel] [PATCH 0/2] Deprecate implicit filters Vladimir Sementsov-Ogievskiy
2019-08-14 10:07 ` [Qemu-devel] [PATCH 1/2] qapi: deprecate drive-mirror and drive-backup Vladimir Sementsov-Ogievskiy
2019-08-14 19:22 ` John Snow
2019-08-15 7:44 ` [Qemu-devel] [libvirt] " Peter Krempa
2019-08-15 21:24 ` John Snow
2019-08-14 10:07 ` [Qemu-devel] [PATCH 2/2] qapi: deprecate implicit filters Vladimir Sementsov-Ogievskiy
2019-08-14 19:27 ` John Snow
2019-08-14 20:34 ` [Qemu-devel] [Qemu-block] " Maxim Levitsky
2019-08-15 10:49 ` [Qemu-devel] " Kevin Wolf
2019-08-15 11:45 ` [Qemu-devel] [libvirt] " Peter Krempa
2019-08-15 14:04 ` Markus Armbruster
2019-08-29 16:45 ` Christophe de Dinechin
2019-08-29 17:57 ` John Snow
2019-08-30 10:07 ` Christophe de Dinechin
2019-08-30 18:11 ` John Snow
2019-09-02 12:04 ` Kevin Wolf
2019-11-22 8:41 ` Markus Armbruster
2019-11-22 11:32 ` Christophe de Dinechin
2019-08-15 16:07 ` [Qemu-devel] " John Snow
2019-08-15 16:48 ` Kevin Wolf
2019-08-15 17:33 ` John Snow
2019-08-15 19:24 ` Markus Armbruster
2019-08-16 8:20 ` Kevin Wolf
2019-08-16 12:33 ` Markus Armbruster [this message]
2019-08-16 12:58 ` Vladimir Sementsov-Ogievskiy
2019-08-15 14:16 ` [Qemu-devel] Exposing feature deprecation to machine clients (was: [PATCH 2/2] qapi: deprecate implicit filters) Markus Armbruster
2019-08-15 17:40 ` John Snow
2019-11-07 18:52 ` [Qemu-devel] Exposing feature deprecation to machine clients Philippe Mathieu-Daudé
2019-11-07 19:13 ` Vladimir Sementsov-Ogievskiy
2019-11-08 6:41 ` Deprecating stuff for 4.2 (was: [Qemu-devel] Exposing feature deprecation to machine clients) Markus Armbruster
2019-11-08 9:36 ` Deprecating stuff for 4.2 Vladimir Sementsov-Ogievskiy
2019-11-08 8:35 ` [Qemu-devel] Exposing feature deprecation to machine clients Max Reitz
2019-08-29 15:59 ` [Qemu-devel] [PATCH 2/2] qapi: deprecate implicit filters Christophe de Dinechin
2019-08-29 17:18 ` [Qemu-devel] [Qemu-block] " John Snow
2019-08-23 9:22 ` [Qemu-devel] " Vladimir Sementsov-Ogievskiy
2019-08-27 20:12 ` John Snow
2019-08-28 9:20 ` Vladimir Sementsov-Ogievskiy
2019-08-28 17:48 ` John Snow
2019-08-29 14:44 ` Peter Krempa
2019-08-29 15:17 ` Vladimir Sementsov-Ogievskiy
2019-08-29 17:50 ` John Snow
2019-08-29 15:00 ` Vladimir Sementsov-Ogievskiy
2019-08-29 15:16 ` Vladimir Sementsov-Ogievskiy
2019-09-02 12:14 ` Kevin Wolf
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87d0h5p9wp.fsf@dusky.pond.sub.org \
--to=armbru@redhat.com \
--cc=den@openvz.org \
--cc=jsnow@redhat.com \
--cc=kwolf@redhat.com \
--cc=libvir-list@redhat.com \
--cc=mreitz@redhat.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=vsementsov@virtuozzo.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.