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

[Anthony Liguori]

On 04/13/2012 09:21 AM, Andreas Färber wrote:
> Am 13.04.2012 16:08, schrieb Paolo Bonzini:
> > Il 13/04/2012 16:06, Andreas Färber ha scritto:
> > > 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.
> >
> > But why should they fail?  This is what I also asked.  If instance-init
> > is deterministic, it will either always or never fail (besides cases
> > like memory allocation which cannot really be handled correctly).
>
> Indeed I am thinking of trivial memory allocation for starters, yes.
> This is not just a theoretical issue as I have two such reports in my
> Bugzilla already.
>
> I do think we need an object_try_new() for said runtime operations such
> as CPU hotplug, and the PowerPCCPU dynamically allocates the opcodes
> table using malloc() that may fail as well (same for g_try_malloc).

Why doesn't it use g_malloc()?

> I see three solutions:
> a) make children a field of the object's state struct (Anthony's i440fx
> approach, requires to know object size in advance) or
> b) allocate in realize (being done in at least some SysBus devices) or
> c) let initfn fail.

Regards,

Anthony Liguori


> On a related matter, another solution to my SoC problem would be to be
> able to add a NULL child property as placeholder (so that the layering
> of naming the property is preserved) and to have an
> object_property_set_child() to fill that in; still needs a second-stage
> constructor function for the CPU-dependent devices though...
>
> Andreas