Re: [Qemu-devel] [PATCH qom-next 04/59] pc: Add CPU as /machine/cpu[n]

[Jan Kiszka <jan.kiszka@siemens.com>]

On 2012-06-08 14:47, Igor Mammedov wrote:
> ----- Original Message -----
>> From: "Jan Kiszka" <jan.kiszka@siemens.com>
>> To: "Andreas Färber" <afaerber@suse.de>
>> Cc: "Igor Mammedov" <imammedo@redhat.com>, "Anthony Liguori" <aliguori@us.ibm.com>, qemu-devel@nongnu.org, "Igor
>> Mammedov" <niallain@gmail.com>, "Paolo Bonzini" <pbonzini@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).

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux