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

[Anthony Liguori]

On 02/07/2011 08:05 AM, Markus Armbruster wrote:
> 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.
>    

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