From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:37063) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SeEz1-0003ih-Kw for qemu-devel@nongnu.org; Mon, 11 Jun 2012 20:29:20 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SeEyy-0000K1-Kx for qemu-devel@nongnu.org; Mon, 11 Jun 2012 20:29:19 -0400 Received: from cantor2.suse.de ([195.135.220.15]:42856 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SeEyy-0000Io-B8 for qemu-devel@nongnu.org; Mon, 11 Jun 2012 20:29:16 -0400 Message-ID: <4FD68D52.8020304@suse.de> Date: Tue, 12 Jun 2012 02:29:06 +0200 From: =?ISO-8859-1?Q?Andreas_F=E4rber?= MIME-Version: 1.0 References: <4FD66B8F.4080203@codemonkey.ws> In-Reply-To: <4FD66B8F.4080203@codemonkey.ws> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] Semantics of DeviceState::realized and BlockDriverState List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Kevin Wolf , Paolo Bonzini , qemu-devel , Stefan Hajnoczi 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=3Dtrue, the guest has po= wer > and is active. When realized=3Dfalse, 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 parameter= s > 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(). >=20 > The destructor being invoked does not imply that unrealize() has happen= ed. [...] > 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. >=20 > Regard, >=20 > Anthony Liguori --=20 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N=FCrnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imend=F6rffer; HRB 16746 AG N=FCrnbe= rg