qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH] qmp: add query-qemu-capabilities


From: Stefan Hajnoczi
Subject: Re: [Qemu-devel] [PATCH] qmp: add query-qemu-capabilities
Date: Mon, 25 Feb 2019 17:06:46 +0000
User-agent: Mutt/1.10.1 (2018-07-13)

On Mon, Feb 25, 2019 at 09:50:26AM +0100, Markus Armbruster wrote:
> Stefan Hajnoczi <address@hidden> writes:
> 
> > QMP clients can usually detect the presence of features via schema
> > introspection.  There are rare features that do not involve schema
> > changes and are therefore impossible to detect with schema
> > introspection.
> >
> > This patch adds the query-qemu-capabilities command.  It returns a list
> > of capabilities that this QEMU supports.
> 
> The name "capabilities" could be confusing, because we already have QMP
> capabilities, complete with command qmp_capabilities.  Would "features"
> work?

Sure, will fix.

> > The decision to make this a command rather than something statically
> > defined in the schema is intentional.  It allows QEMU to decide which
> > capabilities are available at runtime, if necessary.
> >
> > This new interface is necessary so that QMP clients can discover that
> > migrating disk image files is safe with cache.direct=off on Linux.
> > There is no other way to detect whether or not QEMU supports this.
> 
> I think what's unsaid here is that we don't want to make a completely
> arbitrary schema change just to carry this bit of information.  We
> could, but we don't want to.  Correct?

Yes, exactly.

> > +{ 'struct': 'QemuCapabilities',
> > +  'data': { 'capabilities': ['QemuCapability'] } }
> > +
> > +##
> > +# @query-qemu-capabilities:
> > +#
> > +# Return the capabilities supported by this QEMU.  Most features can be
> > +# detected via schema introspection but some are not observable from the
> > +# schema.  This command offers a way to check for the presence of such
> > +# features.
> > +#
> > +# Since: 4.0
> > +##
> > +{ 'command': 'query-qemu-capabilities',
> > +  'returns': 'QemuCapabilities' }
> 
> Capabilities are flags: either present or absent, thus effectively
> boolean.  I don't have a specific reason to doubt limiting capabilities
> to boolean.  However, doing QemuCapabilities like
> 
>    { 'struct': 'QemuCapabilities',
>      'data': { 'migrate-with-cache-direct-off-on-linux': 'bool' } }
> 
> could grow to support other values more easily.  What do you think?

Oops, I didn't think of the obvious solution!  Thank you, will fix.

Attachment: signature.asc
Description: PGP signature


reply via email to

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