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