On Thu, Oct 04, 2012 at 03:10:53PM +0200, Igor Mammedov wrote: > On Thu, 04 Oct 2012 14:57:29 +0200 > Andreas Färber <afaer...@suse.de> 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? > > > > 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. > > > I guess no, it's now cpu-as-device that should be next on a queue, since I'm > rewriting this series to use static properties instead so CPU must be a > device.
Whatever we decide on this thread about CPU properties, cpu-as-device seems to be the obvious candidate for "next-in-the-queue", or at least it can be written/discussed in parallel. I plan to submit a new RFC soon. > > Though work would be easier if static props we written&applied on top of > this, it's not like we need working for CPU qdev_prop_set_globals() after this > series. > > > -- Eduardo
