qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Gonglei (Arei)
Subject: Re: [Qemu-devel] [PATCH 0/3] Fix confused output for alias properties
Date: Wed, 17 Sep 2014 02:31:49 +0000

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

Hope for your more detailed information about this, thanks in advance! :)

Best regards,
-Gonglei



reply via email to

[Prev in Thread] Current Thread [Next in Thread]