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

[Kevin Wolf <kwolf@redhat.com>]

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.

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?

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.

A comment in this patch says it means that an object is fully
constructed. So if we add a file_opened state in the block layer, in
order to keep this consistent, it would have to be a state that comes
between INITIALIZED and REALIZED.

Where would we have checks, for example whether the image that you
assign to a block device is really opened? Would QOM commands to create
a link only link to already realised objects? Would each single block
device have to check this during its own realisation phase? Would we
check object_is_realized() or rather bdrv_file_is_opened()? If the
latter, it can't be generic monitor code that checks it.

Let's start with this, I'm sure I'll have more questions...

Kevin