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