|
From: | Anthony Liguori |
Subject: | Re: [Qemu-devel] [PATCH RFC v4 44/44] qom: Introduce CPU class |
Date: | Wed, 14 Mar 2012 15:01:56 -0500 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 |
On 03/14/2012 02:57 PM, Andreas Färber wrote:
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.
Yes, there's quite a lot of refactoring to get to a two stage recursive init. This is why realized isn't a part of QOM/qdev today.
Regards, Anthony Liguori
Andreas
[Prev in Thread] | Current Thread | [Next in Thread] |