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

[Anthony Liguori <anthony@codemonkey.ws>]

On 02/07/2011 08:05 AM, Markus Armbruster wrote:
> Anthony Liguori<anthony@codemonkey.ws>  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.
>    

I'm making steady progress.  I just finished device_add/device_del on a 
plane.  I expect to have QMP fully converted in a couple weeks.

There is a lot more than I anticipated that is not available in QMP vs. 
the HMP so that's going to take a bit more time.


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

Hint: enum shouldn't block usb-ccid.  An enum is equivalent to a string 
property to convert as far as the current command line interface so just 
use a string property with a well documented set of inputs, and let's do 
enums properly.

That's what I was suggesting in my previous replies to this series.

> What would making him drop enum properties from his series accomplish?
>    

We (or maybe just I) have to take QMP more seriously.  I don't want to 
further make device properties incompatible with QMP which is what an 
enum property would do.

> We'd get the same device with an inferior -device interface, which we
> then have to maintain compatibly.
>    

We can retroactively make the command line interface take a symbolic 
value of an enum when it previously took a string with no compatibility 
problem.

But a QMP enum interface may not operate in strings.  If it sends 
integer constants instead of strings, then we'll create a compatibility 
issue.

Regards,

Anthony Liguori