[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: Anthony Liguori
Subject: Re: [Qemu-devel] [PATCH qom-next 1/7] qdev: Push state up to Object
Date: Mon, 11 Jun 2012 16:48:54 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329 Thunderbird/11.0.1

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 {
+} 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 

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.


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.


reply via email to

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