Re: [Qemu-devel] [PATCH 07/23] target-i386: convert cpuid features into properties

[Eduardo Habkost]

On Thu, Oct 04, 2012 at 02:57:29PM +0200, Andreas Färber wrote:
> Am 04.10.2012 14:43, schrieb Eduardo Habkost:
> > On Thu, Oct 04, 2012 at 08:53:22AM +0200, Igor Mammedov wrote:
> >> For x86 CPU classes we were going dynamically generate CPU classes and 
> >> store
> >> pointer to appropriate cpudef from builtin_x86_defs in class field for each
> >> CPU class and then init default feature words values from this field int
> >> x86_cpu_initfn().
> >>
> >> However with qdev_prop_set_globals() in device_initfn() that is called 
> >> before
> >> x86_cpu_initfn() it won't work because defaults in x86_cpu_initfn() will
> >> overwrite whatever was set by qdev_prop_set_globals().
> > 
> > We can set the default values on class_init, instead. The class_init
> > function for each CPU model can get the x86_def_t struct as the data
> > pointer.
> 
> Let's avoid going backwards here, the plan was to have imperative
> initfns, so x86_def_t would go away, no?

It was never my plan, and I still don't see why we would want to do
that.

> 
> I'm catching up my mail on multiple fronts and will continue review,
> IIUC Blue already applied the CPU feature deduplification series so
> according to your roadmap this series is next.

It would be the next series on the queue, yes, but now Anthony wants the
CPU properties to be all static properties (set on the DeviceClass.props
array). (We were discussing this yesterday on #qemu.)

I suggested including this series anyway, and then move the properties
to be static later (after converting CPU to DeviceState), but Anthony
didn't like the idea.


> 
> >> IMHO from general POV it's not correct to set properties before object is
> >> completely created.
> > 
> > If I understood it correctly, the point of all this is to allow
> > properties (and their defaults) to be introspected by just looking at
> > the class, without having to create any object.
> 
> It would be news to me that that was Anthony's plan... Static properties
> are being assigned to the class but populated at instantiation time. We
> do not have class properties as such.

That was the explanation (if I understood it correctly) for why we won't
global properties can't be used to set "dynamic" properties (properties
registered and set on class->instance_init()).

-- 
Eduardo