[Top][All Lists]

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

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

From: Eric Blake
Subject: Re: [Qemu-block] [Qemu-devel] [PATCH 1/2] qmp: Add query-qemu-features
Date: Fri, 29 Mar 2019 10:06:14 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.0

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

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

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

Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

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