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

[Andreas Färber]

Am 11.06.2012 23:48, schrieb Anthony Liguori:
> On 06/11/2012 04:31 PM, Andreas Färber wrote:
>> 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.
> 
> This is not the intention of realize.  There's nothing final about
> realize either.

Final in the sense of second-stage of two stages: No further
construction happens after realize because realize is being deferred to
the latest point possible.

> Realize attempts to give you a hook at the very last moment before you
> can no longer change a device.  In X11, realize happens before a window
> is mapped to the visible screen.  X11 has the same problem where there's
> a relationship between widgets and there's some work that requires that
> the parent widget is known.  realize() provides that last possible hook
> where you can defer the work that requires the parent and children to be
> setup.
> 
> That's what realize achieves.  And unrealize is just the opposite.  It's
> called as soon as you unmap a window and can be used to undo the things
> you did in realize.

We don't seem to be in disagreement except that you say it's not the
intention of realize...

Hook, function or constructor ... it basically does the same thing.

If you want to have differently named hooks doing roughly the same thing
in different contexts, then what is your suggestion? The qdev init model
doesn't fully translate to realize yet, so add DEVICE_STATE_REALIZED to
the qdev state enum as third state?

Andreas

> 
> Regards,
> 
> Anthony Liguori
> 
>>
>> 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