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

[Anthony Liguori <anthony@codemonkey.ws>]

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.

>
> 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).

> 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?

>
> A comment in this patch says it means that an object is fully
> constructed.

That's not really the best wording.  See above.

Regards,

Anthony Liguori

> 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