qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Kevin Wolf <kwolf@redhat.com>
To: John Snow <jsnow@redhat.com>
Cc: qemu-devel@nongnu.org,
	Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>,
	qemu-block@nongnu.org, libvir-list@redhat.com, armbru@redhat.com,
	mreitz@redhat.com, den@openvz.org
Subject: Re: [Qemu-devel] [PATCH 2/2] qapi: deprecate implicit filters
Date: Thu, 15 Aug 2019 12:49:28 +0200	[thread overview]
Message-ID: <20190815104928.GC7415@linux.fritz.box> (raw)
In-Reply-To: <3eded188-0161-d494-194c-9d67da644eb1@redhat.com>

Am 14.08.2019 um 21:27 hat John Snow geschrieben:
> 
> 
> On 8/14/19 6:07 AM, Vladimir Sementsov-Ogievskiy wrote:
> > To get rid of implicit filters related workarounds in future let's
> > deprecate them now.
> > 
> > Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
> > ---
> >  qemu-deprecated.texi      |  7 +++++++
> >  qapi/block-core.json      |  6 ++++--
> >  include/block/block_int.h | 10 +++++++++-
> >  blockdev.c                | 10 ++++++++++
> >  4 files changed, 30 insertions(+), 3 deletions(-)
> > 
> > diff --git a/qemu-deprecated.texi b/qemu-deprecated.texi
> > index 2753fafd0b..8222440148 100644
> > --- a/qemu-deprecated.texi
> > +++ b/qemu-deprecated.texi
> > @@ -183,6 +183,13 @@ the 'wait' field, which is only applicable to sockets in server mode
> >  
> >  Use blockdev-mirror and blockdev-backup instead.
> >  
> > +@subsection implicit filters (since 4.2)
> > +
> > +Mirror and commit jobs inserts filters, which becomes implicit if user
> > +omitted filter-node-name parameter. So omitting it is deprecated, set it
> > +always. Note, that drive-mirror don't have this parameter, so it will
> > +create implicit filter anyway, but drive-mirror is deprecated itself too.
> > +
> >  @section Human Monitor Protocol (HMP) commands
> >  
> >  @subsection The hub_id parameter of 'hostfwd_add' / 'hostfwd_remove' (since 3.1)
> > diff --git a/qapi/block-core.json b/qapi/block-core.json
> > index 4e35526634..0505ac9d8b 100644
> > --- a/qapi/block-core.json
> > +++ b/qapi/block-core.json
> > @@ -1596,7 +1596,8 @@
> >  # @filter-node-name: the node name that should be assigned to the
> >  #                    filter driver that the commit job inserts into the graph
> >  #                    above @top. If this option is not given, a node name is
> > -#                    autogenerated. (Since: 2.9)
> > +#                    autogenerated. Omitting this option is deprecated, it will
> > +#                    be required in future. (Since: 2.9)
> >  #
> >  # @auto-finalize: When false, this job will wait in a PENDING state after it has
> >  #                 finished its work, waiting for @block-job-finalize before
> > @@ -2249,7 +2250,8 @@
> >  # @filter-node-name: the node name that should be assigned to the
> >  #                    filter driver that the mirror job inserts into the graph
> >  #                    above @device. If this option is not given, a node name is
> > -#                    autogenerated. (Since: 2.9)
> > +#                    autogenerated. Omitting this option is deprecated, it will
> > +#                    be required in future. (Since: 2.9)
> >  #
> >  # @copy-mode: when to copy data to the destination; defaults to 'background'
> >  #             (Since: 3.0)
> > diff --git a/include/block/block_int.h b/include/block/block_int.h
> > index 3aa1e832a8..624da0b4a2 100644
> > --- a/include/block/block_int.h
> > +++ b/include/block/block_int.h
> > @@ -762,7 +762,15 @@ struct BlockDriverState {
> >      bool sg;        /* if true, the device is a /dev/sg* */
> >      bool probed;    /* if true, format was probed rather than specified */
> >      bool force_share; /* if true, always allow all shared permissions */
> > -    bool implicit;  /* if true, this filter node was automatically inserted */
> > +
> > +    /*
> > +     * @implicit field is deprecated, don't set it to true for new filters.
> > +     * If true, this filter node was automatically inserted and user don't
> > +     * know about it and unprepared for any effects of it. So, implicit
> > +     * filters are workarounded and skipped in many places of the block
> > +     * layer code.
> > +     */
> > +    bool implicit;
> >  
> >      BlockDriver *drv; /* NULL means no media */
> >      void *opaque;
> > diff --git a/blockdev.c b/blockdev.c
> > index 36e9368e01..b3cfaccce1 100644
> > --- a/blockdev.c
> > +++ b/blockdev.c
> > @@ -3292,6 +3292,11 @@ void qmp_block_commit(bool has_job_id, const char *job_id, const char *device,
> >      BlockdevOnError on_error = BLOCKDEV_ON_ERROR_REPORT;
> >      int job_flags = JOB_DEFAULT;
> >  
> > +    if (!has_filter_node_name) {
> > +        warn_report("Omitting filter-node-name parameter is deprecated, it "
> > +                    "will be required in future");
> > +    }
> > +
> >      if (!has_speed) {
> >          speed = 0;
> >      }
> > @@ -3990,6 +3995,11 @@ void qmp_blockdev_mirror(bool has_job_id, const char *job_id,
> >      Error *local_err = NULL;
> >      int ret;
> >  
> > +    if (!has_filter_node_name) {
> > +        warn_report("Omitting filter-node-name parameter is deprecated, it "
> > +                    "will be required in future");
> > +    }
> > +
> >      bs = qmp_get_root_bs(device, errp);
> >      if (!bs) {
> >          return;
> > 
> 
> This might be OK to do right away, though.
> 
> I asked Markus this not too long ago; do we want to amend the QAPI
> schema specification to allow commands to return with "Warning" strings,
> or "Deprecated" stings to allow in-band deprecation notices for cases
> like these?
> 
> example:
> 
> { "return": {},
>   "deprecated": True,
>   "warning": "Omitting filter-node-name parameter is deprecated, it will
> be required in the future"
> }
> 
> There's no "error" key, so this should be recognized as success by
> compatible clients, but they'll definitely see the extra information.
> 
> Part of my motivation is to facilitate a more aggressive deprecation of
> legacy features by ensuring that we are able to rigorously notify users
> through any means that they need to adjust their scripts.

Who would read this, though? In the best case it ends up deep in a
libvirt log that nobody will look at because there was no error. In the
more common case, the debug level is configured so that QMP traffic
isn't even logged.

Kevin


  parent reply	other threads:[~2019-08-15 10:50 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     ` Kevin Wolf [this message]
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
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=20190815104928.GC7415@linux.fritz.box \
    --to=kwolf@redhat.com \
    --cc=armbru@redhat.com \
    --cc=den@openvz.org \
    --cc=jsnow@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).