On 07/30/2015 10:36 AM, Eric Blake wrote:
> On 07/30/2015 09:53 AM, Markus Armbruster wrote:
>
>>> Or, we could ditch the qtypes lookup altogether, and merely create the
>>> alternate enum as a non-consecutive QTYPE mapping, for one less level of
>>> indirection, as in:
>>>
>>> typedef enum BlockdevRefKind {
>>> BLOCKDEV_REF_DEFINITION = QTYPE_QOBJECT,
>>
>> QTYPE_QDICT, but I get what you mean.
>>
>>> BLOCKDEV_REF_REFERENCE = QTYPE_QSTRING,
>>> };
>>>>> Hmm, your new BlockdevRefKind is basically a subset of qtype_code with >> the members renamed. Could we simply use qtype_code directly? > > We could, except that clients that manipulate the generated struct then > have to know the qtype mapping directly; while keeping symbolic names > lets them do 'foo->type = BLOCKDEV_REF_REFERENCE; foo->reference = xyz;' > as a nice visual indicator of which union member within the struct is > being assigned according to the discriminator. > > I guess I'll see how much code currently manipulates the generated > structs (I already recall from other patches in this series that > blockdev played a bit loose by validating that the QMP was okay and > then using QDict for everything else rather than the generated struct) > and make my decision when posting my RFC patch. Turns out that using it directly was easier, and less code: http://thread.gmane.org/gmane.comp.emulators.qemu/353204/focus=354008 -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
