From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:44548) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SeCOY-0007su-40 for qemu-devel@nongnu.org; Mon, 11 Jun 2012 17:43:31 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SeCOW-0005ha-2X for qemu-devel@nongnu.org; Mon, 11 Jun 2012 17:43:29 -0400 Received: from cantor2.suse.de ([195.135.220.15]:33743 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SeCOV-0005hC-PX for qemu-devel@nongnu.org; Mon, 11 Jun 2012 17:43:27 -0400 Message-ID: <4FD66678.9090702@suse.de> Date: Mon, 11 Jun 2012 23:43:20 +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> <4FD663B2.3020904@suse.de> In-Reply-To: <4FD663B2.3020904@suse.de> 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 23:31, schrieb Andreas F=C3=A4rber: > 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 bloc= k >>>> layer. Thought we discussed that on IRC? >>> >>> I think I still don't understand well enough what 'realized' is reall= y >>> supposed to mean. >> >> realized is essentially the Vcc pin for the device. >> >> When realized =3D true, it means power has been applied to the device = (and >> the guest potentially is interacting with it). >> >> When realized =3D false, it means that power is not applied to the dev= ice >> and the guest is not running. >=20 > That does not match my understanding of realize. >=20 > 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. >=20 > 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.) This is the part that I think can be interpreted as "machine is powered on" or Vcc, but there's nothing stopping us from calling realize at a slightly different point in time for non-device objects not connected to /machine. An SD card for instance could be realized before it is inserted into the drive and thereby before it gets any Vcc. /-F > 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. >=20 > 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. >=20 > A variation of this patch here would be to introduce bool realized whil= e > leaving the qdev state untouched. But that would be in the way of > generalizing static properties to Object, which would mean for the bloc= k > layer that any trivial property would need to be implemented through > manually coded getters and setters. >=20 > 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