[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH qom-next 1/7] qdev: Push state up to Object

From: Andreas Färber
Subject: Re: [Qemu-devel] [PATCH qom-next 1/7] qdev: Push state up to Object
Date: Mon, 11 Jun 2012 23:43:20 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120421 Thunderbird/12.0

Am 11.06.2012 23:31, schrieb Andreas Färber:
> 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ärber:
>>>> Am 10.06.2012 17:49, schrieb Paolo Bonzini:
>>>>> Il 08/06/2012 03:19, Anthony Liguori ha scritto:
>>>>>>> +typedef enum ObjectState {
>>>>>>> +} 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.
>> realized is essentially the Vcc pin for the device.
>> When realized = true, it means power has been applied to the device (and
>> the guest potentially is interacting with it).
>> When realized = false, it means that power is not applied to the device
>> 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.)

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

An SD card for instance could be realized before it is inserted into the
drive and thereby before it gets any Vcc.


> 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

SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg

reply via email to

[Prev in Thread] Current Thread [Next in Thread]