Re: [Qemu-devel] Semantics of DeviceState::realized and BlockDriverState

["Andreas Färber" <afaerber@suse.de>]

Am 12.06.2012 00:05, schrieb Anthony Liguori:
> I think I'm becoming convinced that realized belongs in DeviceState and
> that BlockDriverState does not have a realized equivalent.

> To me, realized represents Vcc.  When realized=true, the guest has power
> and is active.  When realized=false, the guest has lost power.  The
> realize() event is the rising edge of Vcc, unrealized() is the falling
> edge.

Then please name it appropriately: "powered" and "unpowered".

Realization has nothing to do with power, it's an OOP term that
distinguishes from instantiation.

The way this discussion has headed is very unfortunate for me since I
need such a hook for the CPUs today and not in a far future when the
whole of qdev has been refactored to match the QOM type / inheritance
model and qdev has been integrated into linux-user / bsd-user. So if I
don't get ObjectClass::realize for the realize functions we've already
grown (arm, i386) then I'll need some CPUClass::realize mechanism as
(unnecessary?) interim solution to solve the cpu_init() design issue...

Regards,
Andreas

> realize() should be used to take any actions that require all parameters
> to be set that need to happen before the guest has power.  This later
> clause is extremely important.  unrealize() should be used to unset
> anything setup in realize().
> 
> The destructor being invoked does not imply that unrealize() has happened.
[...]
> I think this argues pretty clearly for realize() to not live in Object
> and instead to allow base classes to implement whatever properties make
> sense to them.
> 
> Regard,
> 
> Anthony Liguori

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