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