Am 12.12.2012 15:27, schrieb Igor Mammedov: > 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: >>> 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.
The latest motivation for making the CPU a device was to have the static properties infrastructure for machine/CPU versioning. The global property defaults are set in qdev's instance_init, so object_new() seems fine for that. qdev_[try_]create() would further set the parent bus to SysBus if NULL. The CPU is not a SysBusDevice so I think not using qdev_create() may be safer... Maybe Anthony or Paolo can confirm? Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
