From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:36631) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Scyo9-0007Lg-P8 for qemu-devel@nongnu.org; Fri, 08 Jun 2012 09:00:58 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Scyo7-0002AF-Of for qemu-devel@nongnu.org; Fri, 08 Jun 2012 09:00:53 -0400 Received: from mail-yw0-f45.google.com ([209.85.213.45]:39742) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Scyo7-00029f-IV for qemu-devel@nongnu.org; Fri, 08 Jun 2012 09:00:51 -0400 Received: by yhoo21 with SMTP id o21so1394590yho.4 for ; Fri, 08 Jun 2012 06:00:48 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <4FD1F576.6020601@siemens.com> References: <4FD1F576.6020601@siemens.com> Date: Fri, 8 Jun 2012 15:00:48 +0200 Message-ID: From: "Q (Igor Mammedov)" 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: Jan Kiszka Cc: Igor Mammedov , Anthony Liguori , "qemu-devel@nongnu.org" , =?UTF-8?Q?Andreas_F=C3=A4rber?= , Paolo Bonzini On Fri, Jun 8, 2012 at 2:52 PM, Jan Kiszka wrote: > 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 =C2=A0 = =C2=A0 =C2=A0/machine/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). > 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