From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:57709) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Se5lh-0005d1-QD for qemu-devel@nongnu.org; Mon, 11 Jun 2012 10:39:00 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Se5lc-0005ew-3c for qemu-devel@nongnu.org; Mon, 11 Jun 2012 10:38:57 -0400 Received: from mx1.redhat.com ([209.132.183.28]:19436) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Se5lb-0005eh-Rc for qemu-devel@nongnu.org; Mon, 11 Jun 2012 10:38:52 -0400 Message-ID: <4FD602F6.4080508@redhat.com> Date: Mon, 11 Jun 2012 16:38:46 +0200 From: Kevin Wolf 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: Paolo Bonzini , =?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= , 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 temptatio= n 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. My BlockDriverState doesn't have a Vcc pin, and neither has my Error object. I thought realize() did exist in Object and not only in Device? If so, it must have a more generic meaning. >> Does some magic happen when an object gets realised? From outside, >> what's the difference between an INITIALIZED and a REALIZED object? Is >> it more or less an implementation detail of the base class or is it >> something that affects the object model itself? >=20 > On the rising edge of realized, you typically will validate any paramet= ers and=20 > do any actions necessary based on the parameters. As long as the guest= isn't=20 > running, we want the ability to make changes to the devices that we nor= mally=20 > couldn't change while the guest is running (like updating the CharDrive= rState=20 > pointer). Okay, that matches my understanding. Are all of the checks and the status change of properties (modifiable -> const) done by the specific subclass or is it done by QOM to some degree? >> I think the file_opened state should have more or less the same status >> as the realisation of an object. They are quite similar, so they shoul= d >> both be an implementation detail of their respective class, or they >> should both be baked into the object model. >=20 > I think we need to think about what realized means to a non-Device. Do= es=20 > file_opened have the same logical semantics as the above? Yes, I think it's quite similar, just at an intermediate stage of the object creation. As I imagine it, you would: 1. Create a BlockDriveState 2. Modify the filename property (you can really modify any property if you want for some reason) 3. Call file_open, which opens the image file and may derive some default property values from the image file (flags in the header or whatever). Typical example: The backing file path. I think this would roughly correspond to an extended .bdrv_probe. 4. Modify more properties, overriding any defaults of the image. file_open has made some properties read-only (like the filename), which cannot be modified any more. 5. Call realize. This is the actual .bdrv_open call that makes the BlockDriverState ready to be used. This makes some more properties read-only, like the backing file and format. >> A comment in this patch says it means that an object is fully >> constructed. >=20 > That's not really the best wording. See above. For non-Devices it's still the best explanation I have found. Kevin