3:47 a.m.
New option -compat lets you configure what to do when deprecated
interfaces get used. This is intended for testing users of the
management interfaces. It is experimental.
-compat deprecated-input=<in-policy> configures what to do when
deprecated input is received. Available policies:
* accept: Accept deprecated commands and arguments (default)
* reject: Reject them
* crash: Crash
-compat deprecated-output=<out-policy> configures what to do when
deprecated output is sent. Available output policies:
* accept: Emit deprecated command results and events (default)
* hide: Suppress them
For now, -compat covers only deprecated syntactic aspects of QMP. We
may want to extend it to cover semantic aspects, CLI, and experimental
features.
v5:
* Old PATCH 01-26 merged in commit f57587c7d47.
* Rebased, non-trivial conflicts in PATCH 1 due to Meson, and in PATCH
7 due to visitor changes
* PATCH 1: Comments updated for 5.2 [Eric]
* PATCH 2: Harmless missing initialization fixed [Eric]
* PATCH 3+4: Harmless missing has_FOO = true fixed [Eric]
* PATCH 6+7: Commit message tweaked
v4:
* PATCH 05+07: Temporary memory leak plugged [Marc-André]
* PATCH 23: Rewritten [Marc-André]
* PATCH 24: Comment typo [Marc-André]
* PATCH 30: Memory leaks plugged
v3:
* Rebased, non-trivial conflicts in PATCH 01+26+27+34 due to RST
conversion and code motion
* PATCH 28-29: Old PATCH 28 split up to ease review
* PATCH 30-31: New
* PATCH 32-33: Old PATCH 29 split up to ease review
Comparison to RFC (24 Oct 2019):
* Cover arguments and results in addition to commands and events
* Half-baked "[RFC PATCH 18/19] qapi: Include a warning in the
response to a deprecated command" dropped
See also last item of
Subject: Minutes of KVM Forum BoF on deprecating stuff
Date: Fri, 26 Oct 2018 16:03:51 +0200
Message-ID: <87mur0ls8o.fsf(a)dusky.pond.sub.org>
https://lists.nongnu.org/archive/html/qemu-devel/2018-10/msg05828.html
Cc: Lukáš Doktor <ldoktor(a)redhat.com>
Cc: libguestfs(a)redhat.com
Cc: libvir-list(a)redhat.com
Cc: Daniel P. Berrange <berrange(a)redhat.com>
Cc: Peter Krempa <pkrempa(a)redhat.com>
Cc: Kevin Wolf <kwolf(a)redhat.com>
Markus Armbruster (8):
qemu-options: New -compat to set policy for deprecated interfaces
qapi: Implement deprecated-output=hide for QMP command results
qapi: Implement deprecated-output=hide for QMP events
qapi: Implement deprecated-output=hide for QMP event data
qapi: Implement deprecated-output=hide for QMP introspection
qapi: Implement deprecated-input=reject for QMP commands
qapi: Implement deprecated-input=reject for QMP command arguments
qapi: New -compat deprecated-input=crash
qapi/compat.json | 52 ++++++++++++
qapi/introspect.json | 2 +-
qapi/qapi-schema.json | 1 +
include/qapi/compat-policy.h | 20 +++++
include/qapi/qmp/dispatch.h | 1 +
include/qapi/qobject-input-visitor.h | 9 +++
include/qapi/qobject-output-visitor.h | 9 +++
include/qapi/visitor-impl.h | 6 ++
include/qapi/visitor.h | 18 +++++
monitor/monitor-internal.h | 3 -
monitor/misc.c | 2 -
monitor/qmp-cmds-control.c | 100 +++++++++++++++++++++---
qapi/qapi-visit-core.c | 18 +++++
qapi/qmp-dispatch.c | 17 ++++
qapi/qobject-input-visitor.c | 29 +++++++
qapi/qobject-output-visitor.c | 19 +++++
softmmu/vl.c | 17 ++++
storage-daemon/qemu-storage-daemon.c | 2 -
tests/test-qmp-cmds.c | 91 +++++++++++++++++++--
tests/test-qmp-event.c | 41 ++++++++++
qapi/meson.build | 1 +
qapi/trace-events | 2 +
qemu-options.hx | 22 ++++++
scripts/qapi/commands.py | 14 ++--
scripts/qapi/events.py | 22 +++++-
scripts/qapi/visit.py | 15 ++++
tests/qapi-schema/qapi-schema-test.json | 20 +++--
tests/qapi-schema/qapi-schema-test.out | 20 ++---
28 files changed, 522 insertions(+), 51 deletions(-)
create mode 100644 qapi/compat.json
create mode 100644 include/qapi/compat-policy.h
--
2.26.2
7:45 a.m.
Some general comments on using the patch:
* For libguestfs I chose to add
-compat deprecated-input=reject,deprecated-output=hide
This is only enabled in developer builds of libguestfs when we
are running qemu directly (not via libvirt). The patch for
this is attached.
* What's the point/difference in having reject vs crash?
* I hope that by hiding deprecated QAPI fields we may detect
errors in libguestfs, but I suspect what'll happen is it'll
cause fall-back behaviour which might be harder to detect.
* Be *really* good to have this for command line parameters!
Notes on the attached patch:
* https://libguestfs.org/guestfs-building.1.html
* Simple test:
LIBGUESTFS_BACKEND=direct \
LIBGUESTFS_HV=~/d/qemu/build/x86_64-softmmu/qemu-system-x86_64 \
./run libguestfs-test-tool
* Run the full test suite:
LIBGUESTFS_HV=~/d/qemu/build/x86_64-softmmu/qemu-system-x86_64 \
make -k check-direct
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW
7:54 a.m.
On Mon, Sep 21, 2020 at 13:45:14 +0100, Richard W.M. Jones wrote:
Some general comments on using the patch:
* For libguestfs I chose to add
-compat deprecated-input=reject,deprecated-output=hide
This is only enabled in developer builds of libguestfs when we
are running qemu directly (not via libvirt). The patch for
this is attached.
* What's the point/difference in having reject vs crash?
I'll be adding the following documentation for the qemu.conf entry in
libvirt controling the feature:
+# The "reject" option is less harsh towards the VMs but some code paths ignore
+# errors reported by qemu and thus it may not be obvious that a deprecated
+# command/field was used, thus it's suggested to use the "crash" option
instead.
7:58 a.m.
On Mon, Sep 21, 2020 at 02:54:15PM +0200, Peter Krempa wrote:
On Mon, Sep 21, 2020 at 13:45:14 +0100, Richard W.M. Jones wrote:
> Some general comments on using the patch:
>
> * For libguestfs I chose to add
>
> -compat deprecated-input=reject,deprecated-output=hide
>
> This is only enabled in developer builds of libguestfs when we
> are running qemu directly (not via libvirt). The patch for
> this is attached.
>
> * What's the point/difference in having reject vs crash?
I'll be adding the following documentation for the qemu.conf entry in
libvirt controling the feature:
+# The "reject" option is less harsh towards the VMs but some code paths
ignore
+# errors reported by qemu and thus it may not be obvious that a deprecated
+# command/field was used, thus it's suggested to use the "crash" option
instead.
I'm not sure if libguestfs should use reject or crash. But since most
of the benefit of this is going to be in detecting deprecated CLI
parameters in future, reject should be sufficient for us.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html
7:56 a.m.
On Mon, 14 Sep 2020 at 09:55, Markus Armbruster <armbru(a)redhat.com> wrote:
New option -compat lets you configure what to do when deprecated
interfaces get used. This is intended for testing users of the
management interfaces. It is experimental.
-compat deprecated-input=<in-policy> configures what to do when
deprecated input is received. Available policies:
* accept: Accept deprecated commands and arguments (default)
* reject: Reject them
* crash: Crash
-compat deprecated-output=<out-policy> configures what to do when
deprecated output is sent. Available output policies:
* accept: Emit deprecated command results and events (default)
* hide: Suppress them
For now, -compat covers only deprecated syntactic aspects of QMP. We
may want to extend it to cover semantic aspects, CLI, and experimental
features.
Some bikeshedding on option naming...
If this only covers QMP, should we make the argument to -compat
have a name that expresses that? eg deprecated-qmp-input,
deprecated-qmp-output ?
Also, it seems a bit repetitive to say 'deprecated' here all
the time -- do you have a future use of -compat in mind which
would be to adjust something that is *not* deprecated ? If
not, maybe the 'deprecated' part should be in the option name
rather than in every argument, eg
-deprecation-compat qmp-input=crash,qmp-output=hide,cli-option=reject
?
thanks
-- PMM
9:58 a.m.
Peter Maydell <peter.maydell(a)linaro.org> writes:
On Mon, 14 Sep 2020 at 09:55, Markus Armbruster
<armbru(a)redhat.com> wrote:
>
> New option -compat lets you configure what to do when deprecated
> interfaces get used. This is intended for testing users of the
> management interfaces. It is experimental.
>
> -compat deprecated-input=<in-policy> configures what to do when
> deprecated input is received. Available policies:
>
> * accept: Accept deprecated commands and arguments (default)
> * reject: Reject them
> * crash: Crash
>
> -compat deprecated-output=<out-policy> configures what to do when
> deprecated output is sent. Available output policies:
>
> * accept: Emit deprecated command results and events (default)
> * hide: Suppress them
>
> For now, -compat covers only deprecated syntactic aspects of QMP. We
> may want to extend it to cover semantic aspects, CLI, and experimental
> features.
Some bikeshedding on option naming...
If this only covers QMP, should we make the argument to -compat
have a name that expresses that? eg deprecated-qmp-input,
deprecated-qmp-output ?
It's only implemented for QMP so far. But we really want it for all
external interfaces for use by machines. Today, that's QMP and CLI.
Naming the parameters deprecated-qmp-{input,output} leads to separate
settings for QMP and CLI.
Naming them just deprecated-{input,output} leads to a single set of
settings common to all externeal interfaces, or to sugar for setting all
the deprecated-*-{input,output} we may have.
I don't think getting it wrong now would be a big deal. No excuse for
getting it wrong unthinkingly :)
Also, it seems a bit repetitive to say 'deprecated' here all
the time -- do you have a future use of -compat in mind which
would be to adjust something that is *not* deprecated ? If
not, maybe the 'deprecated' part should be in the option name
rather than in every argument, eg
-deprecation-compat qmp-input=crash,qmp-output=hide,cli-option=reject
?
My cover letter hints at such future uses: "We may want to extend it to
cover [...] experimental features." Something like
-compat experimental-input=reject,experimental-output=hide
11:28 a.m.
On Mon, 21 Sep 2020 at 15:58, Markus Armbruster <armbru(a)redhat.com> wrote:
Peter Maydell <peter.maydell(a)linaro.org> writes:
> If this only covers QMP, should we make the argument to -compat
> have a name that expresses that? eg deprecated-qmp-input,
> deprecated-qmp-output ?
It's only implemented for QMP so far. But we really want it for all
external interfaces for use by machines. Today, that's QMP and CLI.
Naming the parameters deprecated-qmp-{input,output} leads to separate
settings for QMP and CLI.
I think that's a good thing. I might have fixed up my handling
of QMP to avoid deprecated behaviours but not yet got round to
doing that for my command line option choices (or vice-versa).
> Also, it seems a bit repetitive to say 'deprecated' here
all
> the time -- do you have a future use of -compat in mind which
> would be to adjust something that is *not* deprecated ? If
> not, maybe the 'deprecated' part should be in the option name
> rather than in every argument, eg
>
> -deprecation-compat qmp-input=crash,qmp-output=hide,cli-option=reject
>
> ?
My cover letter hints at such future uses: "We may want to extend it to
cover [...] experimental features."
Ah, I read "-compat covers only deprecated syntactic aspects of QMP. We
may want to extend it to cover semantic aspects, CLI, and experimental
features." as implying "deprecated semantic aspects, deprecated CLI,
and deprecated experimental features"...
thanks
-- PMM
1553
days inactive
1560
days old
6 comments
4 participants
participants (4)
-
Markus Armbruster -
Peter Krempa -
Peter Maydell -
Richard W.M. Jones