qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [RFC 04/34] qdev: Prepare "realized" property


From: Eduardo Habkost
Subject: Re: [Qemu-devel] [RFC 04/34] qdev: Prepare "realized" property
Date: Wed, 12 Dec 2012 16:44:19 -0200
User-agent: Mutt/1.5.21 (2010-09-15)

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



reply via email to

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