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: Paolo Bonzini
Subject: Re: [Qemu-devel] [PATCH 0/3] Fix confused output for alias properties
Date: Tue, 16 Sep 2014 16:36:30 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0

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

Paolo



reply via email to

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