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 - . 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
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
