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

[Andreas Färber]

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

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.
> 
> 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