On Fri, Jun 8, 2012 at 2:52 PM, Jan Kiszka <jan.kis...@siemens.com> wrote: > On 2012-06-08 14:47, Igor Mammedov wrote: >> ----- Original Message ----- >>> From: "Jan Kiszka" <jan.kis...@siemens.com> >>> To: "Andreas Färber" <afaer...@suse.de> >>> Cc: "Igor Mammedov" <imamm...@redhat.com>, "Anthony Liguori" >>> <aligu...@us.ibm.com>, qemu-devel@nongnu.org, "Igor >>> Mammedov" <niall...@gmail.com>, "Paolo Bonzini" <pbonz...@redhat.com> >>> 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). > then there is little merit in playing in-place game since allocation of containing object may fail as well resulting in abort just a bit earlier.
> Jan > > -- > Siemens AG, Corporate Technology, CT T DE IT 1 > Corporate Competence Center Embedded Linux
