On 04/13/2012 09:06 AM, Andreas Färber wrote:
Am 13.04.2012 16:00, schrieb Anthony Liguori:
On 04/13/2012 08:36 AM, Andreas Färber wrote:
Am 13.04.2012 09:17, schrieb Paolo Bonzini:
initfn is unable to handle errors btw, which is another reason to do
object creations in a second-stage constructor.
What error handling do you need specifically? You could add an Error **
argument to object_{new,initialize{,_with_type} too as soon as you have
a use for that.
My point was that .instance_init functions always need to succeed
(they're void and have no Error** argument and object_new() does not
return NULL). Allocating a new object in an initfn may fail though.
How would it fail?
The instance_init shouldn't have any side effects nor should it be
affected by external factors.
I'm still talking about the (pretty clear to me) graph that I posted.
There, object A's init function creates a new qdev object - .
instance_init should not call qdev_init(). That would be a bug.
Regards,
Anthony Liguori
Creating
an object can fail - fatally or non-fatally.
And yes, exactly my point, currently initfn (first stage) cannot fail,
only the second stage (DeviceClass::init). Which is why I've been saying
we'll need to refactor those "fake composition" usages first before we
declare that we can defer qdev initialization to vl.c.
Andreas
