On 12/06/2016 10:30 AM, Greg Kurz wrote: > On Mon, 5 Dec 2016 15:41:30 -0200 > Eduardo Habkost <ehabk...@redhat.com> 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 <ehabk...@redhat.com> 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 <gr...@kaod.org> 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