[Top][All Lists]

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

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

From: Andreas Färber
Subject: Re: [Qemu-devel] Semantics of DeviceState::realized and BlockDriverState
Date: Tue, 12 Jun 2012 02:29:06 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120421 Thunderbird/12.0

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...


> 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

reply via email to

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