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. 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.
