qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH RFC 0/3] qom: Generalize qdev init to "realize"


From: Anthony Liguori
Subject: Re: [Qemu-devel] [PATCH RFC 0/3] qom: Generalize qdev init to "realize"
Date: Tue, 27 Mar 2012 13:56:07 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120310 Thunderbird/11.0

On 03/27/2012 11:46 AM, Paolo Bonzini wrote:
Il 27/03/2012 18:33, Peter Maydell ha scritto:
Yes, I haven't reviewed this series yet, but my expectation would be that
realize propagates and that the default implementation of
DeviceClass::realize() would explicitly *not* propagate and instead just
call ::init.
So who calls realize for non-qdev QOM objects which are children of
qdev QOM objects?

I really don't like having the object lifecycle methods be different
for DeviceClass than for base objects if we can avoid it.

The way I read it was that the "realize" property propagates to the
children and calls either the "realize" or "reset" method (in the
appropriate order).

Correct.

We would probably want to have two methods in Object:

/* realize yourself */
void realize(Error **errp);

/* realize your children */
void realize_children(Error **errp);

The actual realize property would call this->realize(errp); then this->realize_children(errp) modulo some cleverness to support transversal ordering.

That means usually, you can just implement realize() and rely on the standard child realize support. But you could overload realize_children() if you needed to.

realize_children() would propagate to child<> properties. All child<> properties trace their parentage back to the object_get_root() device. So you can realize() the entire device/object model by setting the top level realize property.


DeviceClass::realize() would also do other things done currently by
qdev_init, such as register vmstate,

Correct. I think DeviceClass::realize() should call DeviceClass::init() to start out with. Then we can refactor incrementally to move stuff from ::init() to ::realize(). Some parts of :init() will get moved to the constructor.

so there would still be a
separation between DeviceClass::realize and DeviceClass::init (we do not
want yet another pass through the whole tree).

qdev_init would be a thin wrapper around object_realize that takes care
of freeing the object when init fails.

Absolutely.

Regards,

Anthony Liguori


Is this correct?

Paolo




reply via email to

[Prev in Thread] Current Thread [Next in Thread]