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

[Markus Armbruster <armbru@redhat.com>]

Eric Blake <eblake@redhat.com> writes:

> 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.

Yes, please!

>> 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

That's life.

I fully expect the consumers of QMP introspection to get a few things
wrong initially, requiring their users to upgrade to fixed versions.
That's life, too.

>          (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).

In my opinion, attempting to support old versions of QEMU is a complete
waste of resources unless you actually test them to stop the bit-rot.

RHEL-6 0.12 is by now quite different from upstream 0.12.  Unlike
upstream 0.12, it's actually still relevant and useful today.

I encourage you to identify relevant upstream and downstream versions,
keep them tested, and drop support for the rest.