qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v2] qom: Introduce object_realize_nofail()


From: Andreas Färber
Subject: Re: [Qemu-devel] [PATCH v2] qom: Introduce object_realize_nofail()
Date: Fri, 13 Apr 2012 16:06:19 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120312 Thunderbird/11.0

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



reply via email to

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