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