From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([140.186.70.92]:54287)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <anthony@codemonkey.ws>) id 1RsGrc-0007ej-3f
	for qemu-devel@nongnu.org; Tue, 31 Jan 2012 11:47:31 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <anthony@codemonkey.ws>) id 1RsGrW-0007rp-CV
	for qemu-devel@nongnu.org; Tue, 31 Jan 2012 11:47:24 -0500
Received: from mail-pz0-f45.google.com ([209.85.210.45]:43396)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <anthony@codemonkey.ws>) id 1RsGrW-0007rl-6y
	for qemu-devel@nongnu.org; Tue, 31 Jan 2012 11:47:18 -0500
Received: by dadp14 with SMTP id p14so129086dad.4
	for <qemu-devel@nongnu.org>; Tue, 31 Jan 2012 08:47:17 -0800 (PST)
Message-ID: <4F281B11.2050306@codemonkey.ws>
Date: Tue, 31 Jan 2012 10:47:13 -0600
From: Anthony Liguori <anthony@codemonkey.ws>
MIME-Version: 1.0
References: <1327604460-31142-1-git-send-email-aliguori@us.ibm.com>	<1327604460-31142-7-git-send-email-aliguori@us.ibm.com>	<4F27FBE6.7040800@siemens.com>
	<4F27FEFD.5070507@codemonkey.ws>	<4F28000B.5060406@siemens.com>
	<4F280184.3080607@redhat.com>	<4F2812E3.6010206@codemonkey.ws>
	<4F281498.9030406@siemens.com>
In-Reply-To: <4F281498.9030406@siemens.com>
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] [PATCH 06/15] piix: create i8254 through
	composition
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Jan Kiszka <jan.kiszka@siemens.com>
Cc: Peter Maydell <peter.maydell@linaro.org>, Anthony Liguori <aliguori@us.ibm.com>, "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>, Markus Armbruster <armbru@redhat.com>, Avi Kivity <avi@redhat.com>, Paolo Bonzini <pbonzini@redhat.com>

On 01/31/2012 10:19 AM, Jan Kiszka wrote:
> On 2012-01-31 17:12, Anthony Liguori wrote:
>> On 01/31/2012 08:58 AM, Paolo Bonzini wrote:
>>> On 01/31/2012 03:51 PM, Jan Kiszka wrote:
>>>>>>
>>>>>> BTW, this is yet another benefit of making structures public. You can take the
>>>>>> address of a child and set link fields directly without accessors.
>>>> Well, that has two sides. We introduced properties to avoid this direct
>>>> messing.
>>>>
>>>> Does linking also work without exposing internals?
>>>
>>> Perhaps it doesn't need to expose internals. Just like we create interfaces
>>> automatically when creating a parent object, perhaps we can create children as
>>> well, like
>>>
>>> TypeInfo type_piix3 = {
>>> ...
>>> .children = {
>>> { "pic[0]", TYPE_I8259, offsetof(PIIX3, pic[0]) },
>>> { "pic[1]", TYPE_I8259, offsetof(PIIX3, pic[1]) },
>>> { "pit, TYPE_I8254, offsetof(PIIX3, pit) },
>>> { "rtc", TYPE_RTC, offsetof(PIIX3, rtc) },
>>
>>
>> Eeek.  I absolutely want to avoid any offset based interfaces.
>
> Why?

static void object_initialize(Object *obj)
{
     PIIX3State *s = PIIX3(obj);
     ChildProperty props[] = {
       { "pic[0]", TYPE_I8259, &s->pic[0] },
       { "pic[1]", TYPE_I8259, &s->pic[1] },
     };

     object_property_add_children(obj, props, ARRAY_SIZE(props));
}

Is much nicer IMHO.

>
>>
>> You can just as well do:
>>
>> void object_property_add_child(Object *obj, const char *name,
>>                                  const char *type, Object **child);
>>
>> It could then do:
>>
>> *child = object_new(type);
>
> How does this resolve where the link is stored in the opaque state
> structure?

See above.  Don't use an offset based interface and it's not a problem.

Regards,

Anthony Liguori

>
> Jan
>