On Wed, Dec 12, 2012 at 07:25:01PM +0100, Andreas Färber wrote: > Am 12.12.2012 19:16, schrieb Eduardo Habkost: > > So, just to check if I understood all correctly: > > > > DeviceClass.init() is just the old and deprecated version of > > DeviceClass.realize() (just because the former has no Error parameter), > > but both have exactly the same semantics/purpose, and devices should now > > use DeviceClass.realize() instead. Correct? > > Almost! Some qdev initfns today do things that instance_init should do > and realizefn shouldn't. Creating child devices in qdev initfn tampers > with our future ability to set realized = true recursively.
In those cases, where should the child device cration be moved to? Whatever the answer is, can we have those subtle differences documented inside DeviceClass? I specifically mean documenting the purpose of the init/realize/unrealize function pointers and their semantics/requirements for subclasses, not just documenting the semantics of the "realized" property and device_set_realized(). Knowing what device_set_realize() and qdev_init() are supposed to do when all classes already do what they are supposed to is easy. Knowing what exactly subclasses can/can't to do when setting init/realize/unrealize functions is a bit more complicated. > > The other difference that I see (RFC) is that qdev uses an > only-the-instance's-class-sets-init approach, whereas with QOM any class > in the hierarchy can set/override the "virtual" method but needs to take > care of storing and (if desired) calling the parent's version itself, > i.e. an inversion of control towards child classes. I see. In theory we could change DeviceClass.init() to have the same requirements/semantic, but then we would need to change every class to save the parent's init() function and call it. -- Eduardo