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.
My BlockDriverState doesn't have a Vcc pin, and neither has my Error
object. I thought realize() did exist in Object and not only in Device?
If so, it must have a more generic meaning.
>> Does some magic happen when an object gets realised? From outside,
>> what's the difference between an INITIALIZED and a REALIZED object? Is
>> it more or less an implementation detail of the base class or is it
>> something that affects the object model itself?
>
> On the rising edge of realized, you typically will validate any parameters
> and
> do any actions necessary based on the parameters. As long as the guest isn't
> running, we want the ability to make changes to the devices that we normally
> couldn't change while the guest is running (like updating the CharDriverState
> pointer).
Okay, that matches my understanding.
Are all of the checks and the status change of properties (modifiable ->
const) done by the specific subclass or is it done by QOM to some degree?
>> I think the file_opened state should have more or less the same status
>> as the realisation of an object. They are quite similar, so they should
>> both be an implementation detail of their respective class, or they
>> should both be baked into the object model.
>
> I think we need to think about what realized means to a non-Device. Does
> file_opened have the same logical semantics as the above?
Yes, I think it's quite similar, just at an intermediate stage of the
object creation. As I imagine it, you would:
1. Create a BlockDriveState
2. Modify the filename property (you can really modify any property if
you want for some reason)
3. Call file_open, which opens the image file and may derive some
default property values from the image file (flags in the header or
whatever). Typical example: The backing file path. I think this would
roughly correspond to an extended .bdrv_probe.
4. Modify more properties, overriding any defaults of the image.
file_open has made some properties read-only (like the filename),
which cannot be modified any more.
5. Call realize. This is the actual .bdrv_open call that makes the
BlockDriverState ready to be used. This makes some more properties
read-only, like the backing file and format.
>> A comment in this patch says it means that an object is fully
>> constructed.
>
> That's not really the best wording. See above.
For non-Devices it's still the best explanation I have found.
Kevin
