Re: [Qemu-devel] [PATCH v10 29/30] cpu: Convert CpuInfo into flat union

[Eric Blake]

On 11/11/2015 03:19 AM, Markus Armbruster wrote:

>>> Do we need this to make 2.5?
>>
>> It's true that the introspection will change (instead of seeing flat
>> optional members, you now have to chase down variants).  But I don't
>> think it is pressing enough to rush into 2.5; the change is
>> backwards-compatible no matter when we do it, and introspection clients
>> are going to have to get used to the idea of chasing down different
>> paths to find all members of a struct (that is, if we don't change this
>> until 2.6, I'm sure it won't be the last case of introspection changing
>> while keeping QMP wire format back-compatible as formerly non-variant
>> fields become variant).
> 
> We can mess with the schema as long as the QMP wire format stays
> compatible.
> 
> With introspection, schema changes get exposed in QMP that weren't
> exposed before.  Begs the question whether the ABI promise extends to
> the introspection value.
> 
> I think we don't want to extend it, at least for now.  In other words,
> we refuse to put additional constraints on schema changes to keep the
> introspection value stable.  Makes introspection a bit harder to use.
> Not ideal, but better than committing to constraints we don't even fully
> understand, yet.
> 
> I think we should spell this out introspection documentation.

Sounds like I need to prep a doc patch for 2.5 then.

> 
> Our only example so far is converting between optional members and flat
> unions.  Can we think of others?  Hmm, you found one below.

Converting from optional non-variant to variant, converting from string
to enum, converting from single type to alternate.  Might be other
conversions, and the set of conversions for input types may differ from
those of output conversions.

> Okay.  I guess finding all the examples that matter may take a few
> development cycles.  Perhaps we want to commit to some additional
> compatibility promises for introspection then.

Maybe, but until clients are no longer worried about older clients, it
may be several years before taking advantage of whatever we later
document (as it is, upstream libvirt is just now bumping minimum qemu
support up to 0.12 [thanks to RHEL 6] and discarding older qemu from
RHEL 5 - quite a few years behind upstream qemu 2.5, although it is
finding a lot of code in libvirt that is no longer necessary).

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

signature.asc
Description: OpenPGP digital signature