On 06/08/2012 03:04 PM, Andreas Färber wrote:
Am 08.06.2012 14:52, schrieb Jan Kiszka:
On 2012-06-08 14:47, Igor Mammedov wrote:
----- Original Message -----
From: "Jan Kiszka" <[email protected]>
To: "Andreas Färber" <[email protected]>
Cc: "Igor Mammedov" <[email protected]>, "Anthony Liguori" <[email protected]>,
[email protected], "Igor
Mammedov" <[email protected]>, "Paolo Bonzini" <[email protected]>
Sent: Friday, June 8, 2012 2:36:53 PM
Subject: Re: [Qemu-devel] [PATCH qom-next 04/59] pc: Add CPU as /machine/cpu[n]
On 2012-06-08 14:34, Andreas Färber wrote:
Am 08.06.2012 14:05, schrieb Igor Mammedov:
On Fri, Jun 08, 2012 at 11:11:11AM +0200, Andreas Färber wrote:
Another factor that is making this slightly difficult is that
there are
three APIC subclasses. Currently they all have an instance_size
of
sizeof(APICCommonState) so it could be created in-place if it
actually
is a part (child<>) of the CPU wrt hot-plug. Creating objects
with
object_new() in QOM instance_init is forbidden.
Any particular reason why object_new() in intifn is not
acceptable?
It allocates memory, which may fail. The initfn must not fail, the
realizefn may return an Error object.
Since when do we fail gracefully on OOM again?
Maybe Andreas means that we cannot report error to caller?
If it's a case then lets pass error to object_new() and fail gracefully
or simply abort on OOM.
QEMU's policy on OOM is abort (that's what glib already does for us
theses days).
Nah, that's not the whole truth.
Could you elaborate more on subj?
I've looked at different initfns, many of them call object_property_add() which
may cause
OOM as well. So if object_property_add() is permitted then why not object_new()?
(More on that when I've finished fixing my series.)
Andreas
--
-----
Igor
