On Wed, Dec 12, 2012 at 03:27:24PM +0100, Igor Mammedov wrote: > On Wed, 12 Dec 2012 11:59:01 -0200 > Eduardo Habkost <ehabk...@redhat.com> wrote: > > > On Wed, Dec 12, 2012 at 02:34:08PM +0100, Andreas Färber wrote: > > > Am 05.12.2012 17:49, schrieb Eduardo Habkost: > > [...] > > > > static TypeInfo cpu_type_info = { > > > > .name = TYPE_CPU, > > > > - .parent = TYPE_OBJECT, > > > > + .parent = TYPE_DEVICE, > > > > .instance_size = sizeof(CPUState), > > > > .abstract = true, > > > > .class_size = sizeof(CPUClass), > > > > > > This patch makes the CPU a device and looks good so far but does not > > > initialize the devices in cpu_*_init() like Anthony did in his previous > > > patch. I am unsure whether you forgot to do so or whether you wanted to > > > help keep our new CPU code clean of old-style qdev_init_nofail() calls? > > > Since you don't add a qdev initfn here the main difference will be the > > > devices internally staying in "created" rather than "initialized" state. > > > > I think I used a version without the qdev_init_nofail() as base for this > > series (we had multiple proposals being sent in parallel, in the > > beginning), and in the end I forgot that we had a version with those > > calls being added. > > > > The CPU classes don't set any DeviceClass.init() method, so in theory > > the missing qdev_init() calls wouldn't make any difference by now. On > > the other hand, keeping the device in "created" state sounds bad... but > > maybe this acceptable while we are still converting the CPU realize() > > functions to fit inside the DeviceState initialization abstraction? > Testing shows that lack of qdev_create()/init() doesn't break anything so > far. I was planing to send hot-plug RFC after properties and subclasses for > x86 are done and temporally wrap x86_cpu_realize() inside DeviceClass.init() > so we could use qdev_create()/init() and device_add() for CPU.
It seems to be easy to gradually replace the existing cpu_*_realize() calls inside cpu_*_init() with qdev_init[_nofail]() calls (making DeviceClas.init point to cpu_*_realize()), one architecture at a time. I mean: one day we should kill the cpu_*_init() functions and make it CPU creation/initialization generic code. But while we don't do that, a simple cpu_*_realize()->qdev_init() replacement sounds trivial. But first I want to understand the difference between DeviceClass.init() and the proposed DeviceClass.realize() abstraction (they look exactly the same to me). I just sent a question as reply to Andreas' realizefn RFC. > It's still on my TODO list. Perhaps after I resubmit properties series (I > hope to do it this week), I'll redo hot-plug prototype using as a base my > experimental subclasses branch > https://github.com/imammedo/qemu/commits/x86-cpu-classes.WIP -- Eduardo