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

[Kevin Wolf]

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