From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:35133) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Scyfp-0004tk-28 for qemu-devel@nongnu.org; Fri, 08 Jun 2012 08:52:21 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Scyfi-0000BA-KH for qemu-devel@nongnu.org; Fri, 08 Jun 2012 08:52:16 -0400 Received: from david.siemens.de ([192.35.17.14]:21653) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Scyfi-0000B2-Ak for qemu-devel@nongnu.org; Fri, 08 Jun 2012 08:52:10 -0400 Message-ID: <4FD1F576.6020601@siemens.com> Date: Fri, 08 Jun 2012 14:52:06 +0200 From: Jan Kiszka MIME-Version: 1.0 References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH qom-next 04/59] pc: Add CPU as /machine/cpu[n] List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Igor Mammedov Cc: Paolo Bonzini , Anthony Liguori , "qemu-devel@nongnu.org" , =?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= , Igor Mammedov On 2012-06-08 14:47, Igor Mammedov wrote: > ----- Original Message ----- >> From: "Jan Kiszka" >> To: "Andreas F=C3=A4rber" >> Cc: "Igor Mammedov" , "Anthony Liguori" , qemu-devel@nongnu.org, "Igor >> Mammedov" , "Paolo Bonzini" >> Sent: Friday, June 8, 2012 2:36:53 PM >> Subject: Re: [Qemu-devel] [PATCH qom-next 04/59] pc: Add CPU as /machi= ne/cpu[n] >> >> On 2012-06-08 14:34, Andreas F=C3=A4rber wrote: >>> Am 08.06.2012 14:05, schrieb Igor Mammedov: >>>> On Fri, Jun 08, 2012 at 11:11:11AM +0200, Andreas F=C3=A4rber 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 --=20 Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux