qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 8/8] qom: Make CPU a child of DeviceState


From: Eduardo Habkost
Subject: Re: [Qemu-devel] [PATCH 8/8] qom: Make CPU a child of DeviceState
Date: Wed, 12 Dec 2012 11:59:01 -0200
User-agent: Mutt/1.5.21 (2010-09-15)

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?


> 
> If we merge some patch that adds the "realized" property first (probably
> not through qom-cpu tree then) we could avoid qdev_init*() but the end
> result targetted by Paolo was not to have object creators worry about
> realization at all through recursive realization. So either solution
> needs to be changed later on.

I am interested in this series mainly because of the other features
provided by DeviceState: the static property and global-properties
system. The initialization abstraction provided by DeviceState will be
useful as well, but I also don't know what will be the best approach to
finally make the cpu_*init() functions sane. I still need to take a
better look at your QOM realize() RFC.

-- 
Eduardo



reply via email to

[Prev in Thread] Current Thread [Next in Thread]