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

[Gonglei (Arei)]

Hi, Paolo

> -----Original Message-----
> From: Gonglei (Arei)
> Sent: Wednesday, September 17, 2014 10:32 AM
> To: 'Paolo Bonzini'; Markus Armbruster
> Cc: Huangweidong (C); address@hidden; Michael S. Tsirkin;
> address@hidden; address@hidden; address@hidden; Huangpeng
> (Peter); address@hidden
> Subject: RE: [Qemu-devel] [PATCH 0/3] Fix confused output for alias properties
> 
> > From: Paolo Bonzini [mailto:address@hidden
> > 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 <address@hidden> 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