Re: [Qemu-devel] [PATCH 0/3] Fix confused output for alias properties

[Michael S. Tsirkin]

On Tue, Sep 16, 2014 at 11:34:07AM +0200, Paolo Bonzini wrote:
> Il 16/09/2014 11:16, Markus Armbruster ha scritto:
> >> I think both "str" and "link<block-backend>" actually are a small 
> >> degradation
> >> compared to "drive", and this is why I kept the legacy_name.  But overall I
> >> think it's not really worth the layering violation that patches 2 and 3 
> >> are;
> >> and it's definitely not stable material.
> > 
> > "str" is clearly a degradation for me.  I breaks usage like
> > 
> >     for i in `qemu -device help 2>&1 | sed -n 's/^name "\([^"]*\)".*/\1/p'`
> >     do qemu -device $i,help 2>&1
> >     done | grep =drive
> > 
> > Finds all block device models.  I've done such things many times.
> 
> Just replace "grep =drive" with "fgrep .drive".  Similarly:
> 
>   =chr     -> .chardev  (bonus: matches the command line option)
>   =netdev  -> .netdev
>   =vlan    -> .vlan
>   =macaddr -> .mac
> 
> We probably agree that having "=drive" work sometimes, but not always,
> is the worst of both worlds.  Still doesn't make it stable material, IMO.
> 
> > Agree on the uselessness of "on/off".
> > 
> > Agree on the uselessness of "blocksize" without a definition of the
> > term.
> > 
> > "chr" and "netdev" are like "drive", and replacing them by "str" is a
> > degradation in my book.
> 
> It is, but we're suprisingly consistent in the naming of such
> special-typed properties.  So it's actually a good thing that
> legacy_name provides redundant information.

str really should be for free-form strings.
It makes as much sense to call it as string as it is
to call an integer a string because you type
a string of characters to specify it.


> > Help for enum-valued properties in the form of "prop=ENUM-NAME" is not
> > really helpful without a definition of ENUM-NAME.  It's still useful for
> > finding devices with this kind of property.
> 
> Yes, but here you wouldn't have 'str', you would have the corresponding
> QAPI enum name.  This would be an improvement, though a minor one.
> 
> Paolo