From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:60140) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SdzUc-0008Fb-J6 for qemu-devel@nongnu.org; Mon, 11 Jun 2012 03:56:55 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SdzUW-00064h-67 for qemu-devel@nongnu.org; Mon, 11 Jun 2012 03:56:54 -0400 Received: from cantor2.suse.de ([195.135.220.15]:36306 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SdzUV-00064Z-T9 for qemu-devel@nongnu.org; Mon, 11 Jun 2012 03:56:48 -0400 Message-ID: <4FD5A4BA.5020005@suse.de> Date: Mon, 11 Jun 2012 09:56:42 +0200 From: =?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= MIME-Version: 1.0 References: <1338858018-17189-1-git-send-email-mdroth@linux.vnet.ibm.com> <1338858018-17189-2-git-send-email-mdroth@linux.vnet.ibm.com> <4FD59AA2.3000707@suse.de> <4FD59C3F.2020306@redhat.com> In-Reply-To: <4FD59C3F.2020306@redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH 01/17] qidl: add QEMU IDL processor List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: Peter Maydell , aliguori@us.ibm.com, quintela@redhat.com, Michael Roth , qemu-devel@nongnu.org, owasserm@redhat.com, akong@redhat.com, yamahata@valinux.co.jp Am 11.06.2012 09:20, schrieb Paolo Bonzini: > Il 11/06/2012 09:13, Andreas F=C3=A4rber ha scritto: >>>>>> +The first step is to move your device struct definition to a head= er file. This >>>>>> +header file should only contain the struct definition and any pre= processor >>>>>> +declarations you need to define the structure. This header file = will act as >>>>>> +the source for the QC IDL compiler. >>>> >>>> I don't think this is a fantastic idea -- the device struct should b= e >>>> private to the device, and having it in a standalone header file is >>>> asking for users of the device to illicitly include it and access >>>> internals that they shouldn't. >> But that is exactly where realize is headed. PCIBus, a9mp_priv etc. >> structs will need to be made public so that they can be embedded. >=20 > I thought that was just a convenience choice, not a necessity. The > children objects could just as well be heap-allocated. In that case we'd need to change the instance_init signature. As far as I've understood from our discussions with Anthony, realize must not allocate new objects because that may collide with the recursive realize model, and instance_init is not supposed to fail. Thus the in-place init demonstrated for i440fx and now adopted for prep_pci and my tegra2. Saying "the device struct should be private to the device" leaves virtually no choice, whether for convenience or necessity, and requires also suggesting a design solution for QOM initialization. Andreas --=20 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N=C3=BCrnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imend=C3=B6rffer; HRB 16746 AG N=C3=BC= rnberg