qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 1/4] qapi: Support features for structs


From: Peter Krempa
Subject: Re: [Qemu-devel] [PATCH 1/4] qapi: Support features for structs
Date: Wed, 15 May 2019 13:22:50 +0200
User-agent: Mutt/1.11.4 (2019-03-13)

On Wed, May 15, 2019 at 12:58:46 +0200, Kevin Wolf wrote:
> Am 18.04.2019 um 22:03 hat Markus Armbruster geschrieben:
> > Kevin Wolf <address@hidden> writes:
> > 
> > > Sometimes, the behaviour of QEMU changes compatibly, but without a
> > > change in the QMP syntax (usually by allowing values or operations that
> > > previously resulted in an error). QMP clients may still need to know
> > > whether the extension is available.
> > >
> > > This allows to add a list of features to struct definitions that will be
> > > made visible to QMP clients through schema introspection.
> > 
> > Only a first step, but that's okay.  I think we want to be able to tack
> > features to all user-defined types, commands, and events.  Ideally even
> > to members of enum and object types.
> > 
> > Use case: feature 'deprecated'.  We talked about ways to communicate
> > deprecation to management applications.  Introspection was proposed.
> > Feature 'deprecated' delivers it.
> 
> How does introspection solve the problem? It requires the client to
> actively look for a deprecation instead of notifying it that it is using
> something deprecated.

Well, we can actively poll ..

> Do you expect libvirt to check a full list of all QMP commands, types,
> etc. it ever uses against the schema after starting a VM or something
> like that?

.. similarly to how we asked to be put on the reviewer list for the
deprecated.

We an use our test data which we gather from qemu periodically which
include the QMP schema to extract the list of deprecated features and
store them in git. If we bump the test data and a new deprecated entry
appears the developers will need to asses whether it's used or not and
take the appropriate action.

The appropriate action may also include deriving a capability
information from it and use it to alter libvirt's behaviour which would
then be queried at startup of the VM, but mostly we want to use the new
approach which will replace given deprecated feature as soon as it's
available.

Attachment: signature.asc
Description: PGP signature


reply via email to

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