Eduardo Habkost <ehabk...@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-kw...@redhat.com>
