From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:38221) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Sdzby-0004Da-BP for qemu-devel@nongnu.org; Mon, 11 Jun 2012 04:04:39 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Sdzbt-0007Oe-G5 for qemu-devel@nongnu.org; Mon, 11 Jun 2012 04:04:29 -0400 Received: from cantor2.suse.de ([195.135.220.15]:36789 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Sdzbt-0007OY-6k for qemu-devel@nongnu.org; Mon, 11 Jun 2012 04:04:25 -0400 Message-ID: <4FD5A684.608@suse.de> Date: Mon, 11 Jun 2012 10:04:20 +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> <4FD5A4BA.5020005@suse.de> In-Reply-To: <4FD5A4BA.5020005@suse.de> 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, qemu-devel@nongnu.org, Michael Roth , owasserm@redhat.com, akong@redhat.com, yamahata@valinux.co.jp Am 11.06.2012 09:56, schrieb Andreas F=C3=A4rber: > 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 hea= der file. This >>>>>>> +header file should only contain the struct definition and any pr= eprocessor >>>>>>> +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 = be >>>>> 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. >> >> I thought that was just a convenience choice, not a necessity. The >> children objects could just as well be heap-allocated. >=20 > 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 realiz= e > model, and instance_init is not supposed to fail. Thus the in-place ini= t > 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. Forgot to mention that this has nothing to do with child<> properties. It's about composition, i.e. instantiating on object without needing to know about its inner structure - paradoxically this needs that inner structure to be exposed even if not accessed. 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