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

[Andreas Färber]

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).

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.

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

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