From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:46779) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SeFsO-0004Um-Vd for qemu-devel@nongnu.org; Mon, 11 Jun 2012 21:26:34 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SeFsM-0000EP-C4 for qemu-devel@nongnu.org; Mon, 11 Jun 2012 21:26:32 -0400 Received: from mail-ob0-f173.google.com ([209.85.214.173]:54766) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SeFsM-0000Dd-7c for qemu-devel@nongnu.org; Mon, 11 Jun 2012 21:26:30 -0400 Received: by obbwd20 with SMTP id wd20so8133549obb.4 for ; Mon, 11 Jun 2012 18:26:28 -0700 (PDT) Message-ID: <4FD69AC2.8040903@codemonkey.ws> Date: Mon, 11 Jun 2012 20:26:26 -0500 From: Anthony Liguori MIME-Version: 1.0 References: <4FD66B8F.4080203@codemonkey.ws> <4FD68D52.8020304@suse.de> In-Reply-To: <4FD68D52.8020304@suse.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] Semantics of DeviceState::realized and BlockDriverState List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: =?ISO-8859-1?Q?Andreas_F=E4rber?= Cc: Kevin Wolf , Paolo Bonzini , qemu-devel , Stefan Hajnoczi On 06/11/2012 07:29 PM, Andreas Färber wrote: > 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. Eh? I'm not familiar with it as a OOP term. > 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 I warned you early on that CPUs were not the best place to start... I think the fundamental problem is that CPU wants to be a TYPE_DEVICE. We probably shouldn't have started with it as TYPE_OBJECT. I think that's really the immediate problem that needs to be solved. I think avoiding making it TYPE_DEVICE is what's caused us to attempt to push realized into Object in the first place. Regards, Anthony Liguori