Re: [Qemu-devel] [PATCH qom-cpu 00/15 v8] target-i386: convert CPU features into properties, part 1

[Eduardo Habkost]

On Wed, Jun 05, 2013 at 07:57:11PM +0100, Peter Maydell wrote:
> On 5 June 2013 19:31, Eduardo Habkost <address@hidden> wrote:
> > On Wed, Jun 05, 2013 at 07:29:46PM +0200, Andreas Färber wrote:
> >> Am 05.06.2013 19:17, schrieb Eduardo Habkost:
> >> > We have had this discussion before, and I remember Anthony saying that
> >> > anything set using global properties _must_ be static properties,
> >> > period.
> >>
> >> Obviously I am not aware of that, might that have been an IRC discussion?!
> >
> > Yeah, it was on IRC (on 2012-10-03). Quoting Anthony: "globals not
> > working with non-static properties is a feature, not a bug".
> 
> Did it come with a rationale attached? Seems a bit weird...

Excerpt from the chat:

 <ehabkost> imammedo2: aliguori: what about moving the current version forward, 
and convert that to static properties later, as part of the DeviceState work?
 <ehabkost> because we will need to support global properties only after 
converting to DeviceState, anyway
 <aliguori> imammedo, global properties are a qdev-only thing, i don't want to 
change that
 <aliguori> ehabkost, i think this has to happen as static properties from the 
beginnign
 <aliguori> otherwise we just dig ourselves further into the hole
 <aliguori> and it's so simple
 <aliguori> i can't understand why we'd make it harder than it needs to be :-)
 <ehabkost> aliguori: I don't understand why it has to be so harder, either. we 
could simply make global properties work with the dynamically-registered 
properties  ;-)
 <aliguori> ehabkost, problem #1: you can't introspect dynamic properties
 <aliguori> so if you do that, libvirt can't tell that they're there
 <aliguori> which means you also have to solve that problem
 <aliguori> and the approach bonzini and i agreed to on that was: only use 
static properties when you need to do introspection
 <ehabkost> aliguori: isn't this just a matter of ordering? we could initialize 
the list of properties dynamically, but at class_init time
 <aliguori> not, it has to do with how property introspection works
 <aliguori> b/c it's class based
 <aliguori> static properties are tied to classes
 <aliguori> but dynamic properties have no relationship to the class
 <aliguori> so there's no obvious way to determine whether a class has a 
particular property that's dynamic without instantiating an object first
 <aliguori> it gets a bit hairy
 <ehabkost> aliguori: I would be happy initializing the list of properties on 
class_init time
 <aliguori> that's not possible today
 <ehabkost> if DeviceClass.props were a list (still initialized by class_init) 
instead of an array, it would be much easier
 <aliguori> i've gotta run, but trust me, this rat holes quickly...

-- 
Eduardo