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

[Markus Armbruster <armbru@redhat.com>]

Paolo Bonzini <pbonzini@redhat.com> writes:

> 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

Unlike =drive, this isn't guaranteed to work.

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

I'd consider it for stable.  It's a regression.  Pretty harmless, but
regression all the same.  A pretty harmless regression may be preferable
to a hairy patch.  Tradeoff, should be evaluated by the stable
maintainer.

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

Given our overall consistency track record: yes, it's surprising, and no,
I'm not comfortable relying on us being consistent :)

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

I'd be fine with selectively dropping those legacy_name that are
actually less helpful than name.