From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:37346) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SeCD8-0005Rz-7O for qemu-devel@nongnu.org; Mon, 11 Jun 2012 17:31:43 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SeCD5-0001VC-S9 for qemu-devel@nongnu.org; Mon, 11 Jun 2012 17:31:41 -0400 Received: from cantor2.suse.de ([195.135.220.15]:60807 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SeCD5-0001Tw-Ig for qemu-devel@nongnu.org; Mon, 11 Jun 2012 17:31:39 -0400 Message-ID: <4FD663B2.3020904@suse.de> Date: Mon, 11 Jun 2012 23:31:30 +0200 From: =?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= MIME-Version: 1.0 References: <1339097465-22977-1-git-send-email-afaerber@suse.de> <1339097465-22977-2-git-send-email-afaerber@suse.de> <4FD1530D.4010706@codemonkey.ws> <4FD4C1F3.2010203@redhat.com> <4FD4DB9B.8070208@suse.de> <4FD5AB87.2010503@redhat.com> <4FD5F0D1.8070305@codemonkey.ws> In-Reply-To: <4FD5F0D1.8070305@codemonkey.ws> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH qom-next 1/7] qdev: Push state up to Object List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Kevin Wolf , Paolo Bonzini , Markus Armbruster , qemu-devel@nongnu.org Am 11.06.2012 15:21, schrieb Anthony Liguori: > On 06/11/2012 03:25 AM, Kevin Wolf wrote: >> Am 10.06.2012 19:38, schrieb Andreas F=C3=A4rber: >>> Am 10.06.2012 17:49, schrieb Paolo Bonzini: >>>> Il 08/06/2012 03:19, Anthony Liguori ha scritto: >>>>>> >>>>>> +typedef enum ObjectState { >>>>>> + OBJECT_STATE_INITIALIZED =3D 1, >>>>>> + OBJECT_STATE_REALIZED, >>>>>> +} ObjectState; >>>>> >>>>> I think using a bool would be better since it reduces the >>>>> temptation to >>>>> add additional states. >>>> >>>> In fact someone already discussed having a third state for block >>>> devices... :) >>> >>> I would expect that file_opened state to remain internal to the block >>> layer. Thought we discussed that on IRC? >> >> I think I still don't understand well enough what 'realized' is really >> supposed to mean. >=20 > realized is essentially the Vcc pin for the device. >=20 > When realized =3D true, it means power has been applied to the device (= and > the guest potentially is interacting with it). >=20 > When realized =3D false, it means that power is not applied to the devi= ce > and the guest is not running. That does not match my understanding of realize. To me, realize is the second-stage (final) initialization of an object. It's purpose is to set up an object based on properties set after its initialization, so that it can be fully used. Contrary to the initialization phase, where failure would lead to inability to run finalizers, realization can fail and leaves the object in a defined state so that it can either be realized again with changed properties or deleted, running any finalizers. The main difference to qdev init is that we are working towards replacing the init-after-create pattern with late, central realization so that users have a chance to modify objects through QMP once initialized. (Which is what the don't-create-objects-in-realize and in-place initialization discussion is about.) Thus I do not think this has anything to do with devices or power. A device within a SoC or Super I/O chip that is turned off / powered down may still be there wrt MemoryRegions. It would be possible though to amend realize functionality by overriding realize for DeviceState or specific devices. For block devices I thought the discussion had been that they would get a block-specific open(Error**) method, called after initialization and setting the file name / URL, setting some bool opened state. Some block properties would then depend on "opened" rather than on object_is_realized() and fail otherwise. Realize would still be the final construction of the object based on user-settable properties. A variation of this patch here would be to introduce bool realized while leaving the qdev state untouched. But that would be in the way of generalizing static properties to Object, which would mean for the block layer that any trivial property would need to be implemented through manually coded getters and setters. Regards, Andreas --=20 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N=C3=BCrnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imend=C3=B6rffer; HRB 16746 AG N=C3=BC= rnberg