Re: [Qemu-block] [Qemu-devel] [PATCH 1/2] qmp: Add query-qemu-features

[Eric Blake]

On 3/29/19 8:52 AM, Markus Armbruster wrote:

> The basic idea is simple.  Let me explain with an example.
> 
> Instead of what I proposed above:
> 
>      { 'union': 'BlockdevOptions',
>        'base': { 'driver': 'BlockdevDriver',
>                  '*node-name': 'str',
>                  '*discard': 'BlockdevDiscardOptions',
>                  '*cache': 'BlockdevCacheOptions',
>                  '*read-only': 'bool',
>                  '*auto-read-only': 'bool',
>     +            '*dynamic-auto-read-only': 'bool',
>                  '*force-share': 'bool',
>                  '*detect-zeroes': 'BlockdevDetectZeroesOptions' },
>     [...]
>     }

If I'm summarizing correctly, this is the minimum we could pull off to
get a syntactic witness of the change, in time for 4.0, while leaving:

> 
> permit something like
> 
>      { 'union': 'BlockdevOptions',
>     +  'features': { 'dynamic-auto-read-only': true },
>     [...]
>      }
...

as future work.


> Subjective summary:
> 
> * For the known use cases, query-qemu-features is merely a crutch for
>   getting information into the QAPI QMP schema.  Such crutches are ugly,
>   but in absence of better ideas, ugly wins by default.

That is, this series qualifies as the crutch (if we can't come up with
anything closer in time for 4.0) - but your arguments say we may have
something closer:

> 
> * I think I'd prefer adding @dynamic-auto-read-only to
>   BlockdevOptionsFile, or perhaps to BlockdevOptions.  Takes precedence
>   over @auto-read-only.  Consider deprecating @auto-read-only.

This is interesting. The existing flag keeps its semantics:

Open the file with automatic fallback to read-only, may or may not be
dynamic.

And the new flag is documented as:

Overrides auto-read-only, open the file with automatic fallback to
read-only, guaranteed to be dynamic (or fails if the guarantee cannot be
provided).

I don't know if we need the deprecation or not (especially if our plans
over time are to allow the dynamic behavior in more places than just
file-posix, where a guaranteed failure if not dynamic vs. a sane
fallback to only-on-initial-open may still be useful to some callers),
but the new parameter with the guaranteed semantics is definitely
introspectible, so it is closer to the problem than creating
query-qemu-features.  It also seems like something we could pull
together in a short amount of time.

> 
> * We need command line introspection (old news).
> 
> * A general method to make semantic changes visible syntactically would
>   be useful.  The "augment the QAPI schema with feature flags" idea we
>   discussed in last KVM Forum's hallway track could be a starting point.

These are not 4.0 goals.

> 
> 
> Comments?  Opinions?

Thanks for working on a nice summary, and forcing us to think about the
long-term before taking a short-term hack that we may regret.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3226
Virtualization:  qemu.org | libvirt.org

signature.asc
Description: OpenPGP digital signature