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

[Anthony Liguori]

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