qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH for-2.8] qdev: apply global properties in revers


From: Halil Pasic
Subject: Re: [Qemu-devel] [PATCH for-2.8] qdev: apply global properties in reverse order
Date: Tue, 6 Dec 2016 13:08:02 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0


On 12/06/2016 10:30 AM, Greg Kurz wrote:
> On Mon, 5 Dec 2016 15:41:30 -0200
> Eduardo Habkost <address@hidden> wrote:
> 
>> > On Mon, Dec 05, 2016 at 06:25:55PM +0100, Cornelia Huck wrote:
>>> > > On Mon, 5 Dec 2016 14:48:29 -0200
>>> > > Eduardo Habkost <address@hidden> wrote:
>>> > >   
>>>> > > > On Mon, Dec 05, 2016 at 04:42:00PM +0100, Cornelia Huck wrote:  
>>>>> > > > > On Mon, 05 Dec 2016 16:21:22 +0100
>>>>> > > > > Greg Kurz <address@hidden> wrote:
>>>>> > > > >   
>>>>>> > > > > > The current code recursively applies global properties from 
>>>>>> > > > > > child up to
>>>>>> > > > > > parent. So, if you have:
>>>>>> > > > > > 
>>>>>> > > > > > -global virtio-pci.disable-modern=on
>>>>>> > > > > > -global virtio-blk-pci.disable-modern=off
>>>>>> > > > > > 
>>>>>> > > > > > Then the default value of disable-modern for a virtio-blk-pci 
>>>>>> > > > > > device is on,
>>>>>> > > > > > which looks wrong from an OOP perspective.
>>>>>> > > > > > 
>>>>>> > > > > > This patch reverses the logic, so that a child property always 
>>>>>> > > > > > prevail.  
[...]
>> > compat props should be always applied in the order they appear.
>> > -global should always be applied after compat props.
>> > 
> This is actually the way they're being registered to the global_props
> static list: compat props as they appear in HW_COMPAT_* and then -global
> as they appear on the command line.
> 
>> > So, it looks like we have two additional reasons to just follow
>> > the order the global properties were registered.
>> > 
> Thinking again, maybe we just need to reverse the logic in another
> way: go through global_props and apply the property if the device
> can be casted to the corresponding class (i.e. object_class_dynamic_cast()
> != NULL). I'll try that.
> 

IMHO this is the right thing to do (and would result in the
exactly behavior outlined by Eduardo -- compat props as they
applied appear and then command line props as they appear, what
means inverse ordering in terms of overriding regarding the
result).

Halil




reply via email to

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