Hi, Paolo > -----Original Message----- > From: Gonglei (Arei) > Sent: Wednesday, September 17, 2014 10:32 AM > To: 'Paolo Bonzini'; Markus Armbruster > Cc: Huangweidong (C); aligu...@amazon.com; Michael S. Tsirkin; > ag...@suse.de; qemu-devel@nongnu.org; stefa...@redhat.com; Huangpeng > (Peter); lcapitul...@redhat.com > Subject: RE: [Qemu-devel] [PATCH 0/3] Fix confused output for alias properties > > > From: Paolo Bonzini [mailto:pbonz...@redhat.com] > > Sent: Tuesday, September 16, 2014 10:37 PM > > Subject: Re: [Qemu-devel] [PATCH 0/3] Fix confused output for alias > > properties > > > > 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... > > > Sorry, I can't understand the layering violation on PATCH2 and PATCH3. > AliasProperty struct is QOM object and ObjectProperty is also QOM object, > I just move AliasProperty struct from Object.c to Object.h meanwhile add > a point reference in ObjectProperty struct for AliasProperty. Does this is a > layering violation? >
Ping...? Thanks ! Best regards, -Gonglei > Hope for your more detailed information about this, thanks in advance! :) > > Best regards, > -Gonglei