[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Markus Armbruster
Subject: Re: [Qemu-devel] [PATCH 0/3] Export machine type deprecation info through QMP
Date: Wed, 08 May 2019 11:16:50 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux)

Eduardo Habkost <address@hidden> writes:

> On Tue, May 07, 2019 at 07:07:04AM +0200, Markus Armbruster wrote:
>> 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).
> QAPIfying -machine, -cpu, and -device would be wonderful.
>> 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
> Yes, we can.  I think it's a good idea.  But:
>> instead of ad hoc queries?
> I'm not sure about the "instead of" part.  I don't want perfect
> to be the enemy of done, and I don't want QAPIfication of
> -machine to be a requirement to start reporting machine type
> deprecation information.

Valid point.  Still, I believe we should at least try to predict how the
pieces we create now would fit with the pieces we plan to create later

Note that full QAPIfication of -machine isn't necessary to make QAPI
feature "deprecated" work for machine types.  Turning MachineInfo member
@name into an enum, so we can tack "deprecated" onto its values, would

Such a QAPIfication of machine types is still hard: QOM types are
defined at compile time just like the QAPI schema, but their definition
is distributed, and collected into one place only at run time.  I
discussed this on slide 39 of my "QEMU interface introspection: From
hacks to solutions" talk (KVM Form 2015).  Just for device_add, but it's
just a special case of QOM.  Choices listed there:

* Collect drivers at compile time? Hard...
* Make QAPI schema dynamic? Hard...
* Forgo driver-specific arguments in schema?
  Defeats introspection...

I'd like to add to the last item:

  Provide QOM introspection on par with QAPI schema introspection

The QOM introspection we have (qom-list-types etc. is not on par.

Back to exposing machine type deprecation.

I'm doubtful your proposed solution can be applied widely.  It relies on
adding @support-status to something that provides information on
whatever is deprecated.  The initial use is with a something that is an
ad hoc query, namely query-machines.  To use it, the management
application needs to understand what query-machines' @support-status
applies to.  Certainly feasible.  But I fear every use will be a special
case.  Furthermore, a suitable ad hoc query need not exist.  What then?
Create suitable ad hoc queries just for communicating deprecation?

Instead, I'd like us to think about a more genral solution.  Or perhaps
two: one for properly QAPIfied stuff, and one for QOM.

>> 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.
> It also includes a machine-friendly suggested alternative (which
> I think is even more important that the human-readable message).

I agree we should point to a preferred replacement whenever we deprecate

We have to do it in documentation.  And we generally do, in

How useful would doing it in QMP as well be?  Depends on what management
applications can do with the additional information.

> We could extend QAPI introspection to return that if necessary,
> right?

I'm confident we can come up with *something*.  It might kill the neat
and simple "use QAPI features to communicate deprecation" idea, though.

>> 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>

reply via email to

[Prev in Thread] Current Thread [Next in Thread]