Re: [Qemu-devel] [PATCH 0/3] Export machine type deprecation info through QMP

[Markus Armbruster]

Eduardo Habkost <address@hidden> 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: <address@hidden>