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
