From: Markus Armbruster <armbru@redhat.com>
To: Eduardo Habkost <ehabkost@redhat.com>
Cc: mprivozn@redhat.com, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH 0/3] Export machine type deprecation info through QMP
Date: Tue, 07 May 2019 07:07:04 +0200 [thread overview]
Message-ID: <87imumj1jb.fsf@dusky.pond.sub.org> (raw)
In-Reply-To: <20190423212246.3542-1-ehabkost@redhat.com> (Eduardo Habkost's message of "Tue, 23 Apr 2019 18:22:43 -0300")
Eduardo Habkost <ehabkost@redhat.com> writes:
> This series adds machine type deprecation information to the
> output of the `query-machines` QMP command. With this, libvirt
> and management software will be able to show this information to
> users and/or suggest changes to VM configuration to avoid
> deprecated machine types.
This overlaps with something I want to try, namely using Kevin's
proposed QAPI feature flags for deprecation markings. Let's compare the
two.
To mark something as deprecated with your patches, you add a
@support-status member somewhere, where "somewhere" is related to
"something" by "provides information on".
Example: MachineInfo (returned by query-machines) provides information
on possible values of -machine parameter type. If -machine was
QAPIfied, it would provide information on possible values of a QAPI
object type's member. The type might be anonymous. The member should
be an enum (we currently use 'str' in MachineInfo).
Example: say we want to deprecate block driver "vfat",
i.e. BlockdevDriver member @vfat. Type BlockdevDriver is used in
multiple places; let's ignore all but BlockdevOptions. We need to add
@support-status to something that provides information on
BlockdevDriver, or maybe on BlockdevOptions. There is no ad hoc query
providing information on either of the two, because QAPI/QMP
introspection has been sufficient. What now?
Can we add deprecation information to (general) QAPI/QMP introspection
instead of ad hoc queries?
Kevin's proposed QAPI feature flags[*] extend the QAPI language so that
struct types can optionally have a list of feature flags, which are
strings. Struct types suffice for his immediate needs. I'd like to use
feature flags to mark deprecation by tacking a "deprecated" feature onto
whatever is deprecated. This obviously needs feature support for
everything we want to be able to deprecate: commands, and events, as
well as members of enum and object types.
Example: to deprecate block driver "vfat", add feature "deprecated" to
BlockdevDriver member @vfat.
Unlike your patches, this does not require finding a "somewhere" that
provides information on "something". You simply tack "deprecated" right
onto "something".
Your patches provide more information, however: human-readable messages.
Food for thought :)
[*] Hiding in
Subject: [PATCH 0/4] file-posix: Add dynamic-auto-read-only QAPI feature
Date: Mon, 8 Apr 2019 16:35:39 +0200
Message-Id: <20190408143543.3982-1-kwolf@redhat.com>
next prev parent reply other threads:[~2019-05-07 5:08 UTC|newest]
Thread overview: 72+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-23 21:22 [Qemu-devel] [PATCH 0/3] Export machine type deprecation info through QMP Eduardo Habkost
2019-04-23 21:22 ` Eduardo Habkost
2019-04-23 21:22 ` [Qemu-devel] [PATCH 1/3] qapi: SupportStatusInfo struct Eduardo Habkost
2019-04-23 21:22 ` Eduardo Habkost
2019-04-23 22:23 ` Philippe Mathieu-Daudé
2019-04-24 18:24 ` Eduardo Habkost
2019-04-24 18:24 ` Eduardo Habkost
2019-04-24 8:26 ` Daniel P. Berrangé
2019-04-24 8:26 ` Daniel P. Berrangé
2019-04-24 18:20 ` Eduardo Habkost
2019-04-24 18:20 ` Eduardo Habkost
2019-04-30 10:10 ` Daniel P. Berrangé
2019-04-30 10:10 ` Daniel P. Berrangé
2019-04-30 12:42 ` Eduardo Habkost
2019-04-30 12:42 ` Eduardo Habkost
2019-04-30 12:47 ` Daniel P. Berrangé
2019-04-30 12:47 ` Daniel P. Berrangé
2019-04-25 14:20 ` Wainer dos Santos Moschetta
2019-04-25 17:42 ` Eduardo Habkost
2019-04-25 17:42 ` Eduardo Habkost
2019-04-30 10:03 ` Daniel P. Berrangé
2019-04-30 10:03 ` Daniel P. Berrangé
2019-04-23 21:22 ` [Qemu-devel] [PATCH 2/3] machine: Use SupportStatusInfo for deprecation info Eduardo Habkost
2019-04-23 21:22 ` Eduardo Habkost
2019-04-23 22:26 ` Philippe Mathieu-Daudé
2019-04-23 22:26 ` Philippe Mathieu-Daudé
2019-04-24 1:37 ` David Gibson
2019-04-24 1:37 ` David Gibson
2019-04-24 8:23 ` Daniel P. Berrangé
2019-04-24 8:23 ` Daniel P. Berrangé
2019-04-24 18:29 ` Eduardo Habkost
2019-04-24 18:29 ` Eduardo Habkost
2019-04-23 21:22 ` [Qemu-devel] [PATCH 3/3] qmp: Add deprecation information to query-machines Eduardo Habkost
2019-04-23 21:22 ` Eduardo Habkost
2019-04-24 8:28 ` Daniel P. Berrangé
2019-04-24 8:28 ` Daniel P. Berrangé
2019-04-25 14:54 ` Wainer dos Santos Moschetta
2019-04-25 17:43 ` Eduardo Habkost
2019-04-25 17:43 ` Eduardo Habkost
2019-04-23 21:28 ` [Qemu-devel] [PATCH 0/3] Export machine type deprecation info through QMP no-reply
2019-04-23 21:28 ` no-reply
2019-04-24 7:56 ` Thomas Huth
2019-04-24 8:31 ` Daniel P. Berrangé
2019-04-24 8:31 ` Daniel P. Berrangé
2019-04-24 18:14 ` Eduardo Habkost
2019-04-24 18:14 ` Eduardo Habkost
2019-04-24 18:10 ` Eduardo Habkost
2019-04-24 18:10 ` Eduardo Habkost
2019-04-25 7:38 ` Thomas Huth
2019-04-25 7:38 ` Thomas Huth
2019-04-30 10:11 ` Daniel P. Berrangé
2019-04-30 10:11 ` Daniel P. Berrangé
2019-04-24 8:23 ` Michal Privoznik
2019-04-24 8:23 ` Michal Privoznik
2019-05-07 5:07 ` Markus Armbruster [this message]
2019-05-07 16:18 ` Eduardo Habkost
2019-05-08 9:16 ` Markus Armbruster
2019-05-08 20:28 ` Eduardo Habkost
2019-05-09 8:31 ` Markus Armbruster
2019-05-09 9:14 ` Daniel P. Berrangé
2019-05-09 15:52 ` Eduardo Habkost
2019-05-09 16:08 ` Daniel P. Berrangé
2019-05-09 17:44 ` Eduardo Habkost
2019-05-10 6:28 ` Markus Armbruster
2019-05-10 17:03 ` Eduardo Habkost
2019-05-10 6:19 ` Markus Armbruster
2019-05-10 17:00 ` Eduardo Habkost
2019-05-09 18:19 ` Eduardo Habkost
2019-05-10 9:29 ` Markus Armbruster
2019-05-10 17:17 ` Eduardo Habkost
2019-05-10 17:26 ` Daniel P. Berrangé
2019-05-13 11:49 ` Markus Armbruster
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=87imumj1jb.fsf@dusky.pond.sub.org \
--to=armbru@redhat.com \
--cc=ehabkost@redhat.com \
--cc=mprivozn@redhat.com \
--cc=qemu-devel@nongnu.org \
/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.