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

["Andreas Färber" <afaerber@suse.de>]

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 {
>>>>>> +    OBJECT_STATE_INITIALIZED = 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.
> 
> 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.)

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