[Top][All Lists]

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

Re: [Qemu-devel] [PATCH 1/3] qom-qobject: introduce object_property_{g,

From: Eric Blake
Subject: Re: [Qemu-devel] [PATCH 1/3] qom-qobject: introduce object_property_{g, s}et_ptr
Date: Fri, 24 Feb 2017 10:54:44 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0

On 02/24/2017 09:29 AM, Paolo Bonzini wrote:

>> Here's a non-ducky way to convert between QAPI types.  QAPI guarantees
>> that a pointer to a QAPI type is also valid as pointer to its base type.
>> One can do:
>>     UserDefOne *one;
>>     UserDefOneMore *more;
>>     *(UserDefOne *)more = *one; // get UserDefOne into UserDefOneMore
>>                                 // members not in one are untouched
>>     *one = *(UserDefOne *)more; // set UserDefOne from UserDefOneMore
>>                                 // members not in one are ignored

And rather than having to write the casts yourself, the generator
produces qapi_UserDefOneMore_base() which returns the proper UserDefOne
pointer (giving you a bit more type safety, and isolates you from any
generator change in layout).

>> Would this technique suffice for your problem?
> I am not sure.  What I'm trying to do here is to keep backwards
> compatibility in case a device provides UserDefOneMore for a well-known
> property name, and another device provides UserDefOneAnother.  As long
> as all devices provide the same (duck-typed) base class, things work.
> Maybe the right thing to do would be to define a union, but I wasn't
> sure it was possible to do that in a fully backwards compatible way (can
> you define a union where the discriminator is optional, for example?).

Not yet, although I've discussed the idea of an optional discriminator
several times before.  As soon as we have a killer use case where an
optional discriminator makes sense, it shouldn't be too hard to add that
support into the generator.

> If you're setting UserDefOne from UserDefOneMore, some of the values are
> going to be lost.  Presumably there was a reason why you used
> UserDefOneMore, and therefore an error is the safe bet.
> If you're getting UserDefOne from UserDefOneMore, some of the values are
> going to be lost.  However, it's reasonable that you didn't even know
> that UserDefOneMore existed, which makes it sensible to allow reading
> into a covariant type.

How often to we add qapi subtypes, but not adjust the rest of the code
base to cope with it existing?  Is it going to be less of a maintenance
burden just patching all the uses of the property getters to deal with
the new type than it is to keep the non-strict visitor?

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

Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

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