Il 16/09/2014 16:32, Markus Armbruster ha scritto: > 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.
If it doesn't, when we've been consistent so far, it's a bug. >> 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 :) The point of stuff like QOM is exactly to force us to be consistent. No, it doesn't always work. But patches 2 and 3 really are a layering violation. I have no idea how to bring back "drive" without introducing a layering violation somewhere, but this one is really too much... Paolo
