qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v3] qmp: expose list of supported character devi


From: Eric Blake
Subject: Re: [Qemu-devel] [PATCH v3] qmp: expose list of supported character device backends
Date: Tue, 11 Feb 2014 09:24:07 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0

On 02/11/2014 08:51 AM, Luiz Capitulino wrote:

>>>> +##
>>>> +{ 'type': 'ChardevBackendInfo', 'data': {'name': 'str'} }
>>>
>>> We already have ChardevBackend, it's an union though. I'm wondering if
>>> you could change it to an enum and use it instead of plain 'str'?
>>

>> and we also document in qapi-code-gen.txt that when using
>> 'discriminator', you either have to have a base class (and the
>> discriminator is a string-typed member of that base class), or the
>> discriminator is {} because it is an anonymous union.  But I'm asking
>> about yet another situation, of having a typed discriminator with no
>> change to the wire format (no base class), something like:
>>
>> { 'enum': 'ChardevBackendTypes', [ 'file', 'serial', ... ] }
>> { 'union': 'ChardevBackend',
>>   'discriminator': 'ChardevBackendTypes',
>>   'data': { 'file': 'ChardevFile', ...
>>
>> The benefit of such a plan is that we then have an introspectible enum
>> of all possible backends known at compile time (ChardevBackendTypes),
>> and the new addition in this patch becomes:
>>
>> { 'type': 'ChardevBackendInfo',
>>   'data': {'name', 'ChardevBackendTypes' } }
>>
>> rather than raw 'str', while still allowing potential future additions
>> of additional backend info.  Note that there would still be a difference
>> between ChardevBackendTypes (an enum of all possible known types at
>> compile time) vs. query-chardev-backends (a runtime list of the possible
>> types that can be used for this particular machine, even if it is a
>> subset of all possible ChardevBackendTypes).
> 
> Do you envision whether, by applying Martin's patch now, it would be
> compatible to do what you suggest on top?

Yes, changing 'str' to an enum type should not cause any change to the
actual QMP wire format, so it is an improvement that could be made
later.  I see nothing preventing us from taking Martin's patch as
currently written, even if we do add later patches to make it more typesafe.

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