qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 03/16] qdev-properties: add PROP_TYPE_ENUM


From: Markus Armbruster
Subject: Re: [Qemu-devel] [PATCH 03/16] qdev-properties: add PROP_TYPE_ENUM
Date: Mon, 07 Feb 2011 15:05:13 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux)

Anthony Liguori <address@hidden> writes:

> On 02/07/2011 04:43 AM, Alon Levy wrote:
>> On Mon, Feb 07, 2011 at 09:53:44AM +0100, Markus Armbruster wrote:
[...]
>>> Okay, let's examine how your enumeration properties work.
>>>
>>> An enumeration property describes a uint32_t field of the state object.
>>> Differences to ordinary properties defined with DEFINE_PROP_UINT32:
>>>
>>> * info is qdev_prop_enum instead of qdev_prop_uint32.  Differences
>>>    between the two:
>>>
>>>    - parse, print: symbolic names vs. numbers
>>>
>>>    - name, print_options: only for -device DRIVER,\? (and name's use
>>>      there isn't particularly helpful)
>>>      
>> Why do you say that? this is being used by libvirt to get the names of the
>> supported backends for the ccid-card-emulated device.
>>    
>
> This is wrong.
>
> Libvirt should query this information through QMP.

"We should make this information readily available through QMP", you
want to say ;)

>                                                     This is my main
> concern with enums.  If there isn't a useful introspection interface,
> libvirt is going to do dumb things like query help output.

Beggars can't be choosers.

> This has been a nightmare historically and I'm not inclined to repeat it.

No argument, but we can hardly expect poor Alon to finish the QMP job
just to get his usb-ccid device in.

What would making him drop enum properties from his series accomplish?
We'd get the same device with an inferior -device interface, which we
then have to maintain compatibly.



reply via email to

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