Paolo Bonzini <pbonz...@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.
