Re: [Qemu-devel] [PATCH RFC v4 44/44] qom: Introduce CPU class

[Andreas Färber]

Am 14.03.2012 20:48, schrieb Anthony Liguori:
> On 03/14/2012 03:37 PM, Igor Mitsyanko wrote:
>> On 13.03.2012 3:13 PM, Andreas Färber wrote:
>>
>>> In SysBusDeviceClass etc. we use the specific object type, too.
>>> Obviously my CPU is the first "new" QOM type, so we can go different
>>> ways if we want to. As long as it's a CPU-specific mechanism, using the
>>> specific type avoids some casts.
>>>
>>>> It will be easier to generalize later qdev code and not make special
>>>> case when
>>>> adding cpus.
>>>
>>> I never heard anyone wanting to generalize reset so far. I don't think
>>> it belongs into Object at least. Maybe DeviceState. Anthony? Paolo?
>>>
>>
>> We can have a special object for this, let's call it ResetLine for
>> example, with
>> methods ResetLine::connect, ResetLine::assert or something like that.
>> Different
>> ResetLine objects could trigger reset of different sets of subdevices,
>> just like
>> real hardware can have several reset types (for example, STM32 has 3
>> different
>> reset types).
> 
> I've explored a bunch of different models for this.  My current thinking
> is a realized:bool property that when set, would call a realize()
> virtual method and when unset would call an unrealize() virtual method. 
> The default implementation of [un]realize() would propagate the change
> to all composition children.

I've found that model not to work with today's qdev remainders: We often
have a dependency tree of initfn and init a.k.a. realize functions, so
that we can't clearly separate between the two to do recursive
processing. Unless we do a three-stage initialization of Object::initfn,
what-is-now-DeviceState::init, Object::realize.

Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg