From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([140.186.70.92]:55472)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <anthony@codemonkey.ws>) id 1QWwGo-0003C2-C4
	for qemu-devel@nongnu.org; Wed, 15 Jun 2011 16:01:00 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <anthony@codemonkey.ws>) id 1QWwGm-000197-In
	for qemu-devel@nongnu.org; Wed, 15 Jun 2011 16:00:58 -0400
Received: from mail-yi0-f45.google.com ([209.85.218.45]:64076)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <anthony@codemonkey.ws>) id 1QWwGm-00018t-7J
	for qemu-devel@nongnu.org; Wed, 15 Jun 2011 16:00:56 -0400
Received: by yia25 with SMTP id 25so582721yia.4
	for <qemu-devel@nongnu.org>; Wed, 15 Jun 2011 13:00:55 -0700 (PDT)
Message-ID: <4DF90F74.7090206@codemonkey.ws>
Date: Wed, 15 Jun 2011 15:00:52 -0500
From: Anthony Liguori <anthony@codemonkey.ws>
MIME-Version: 1.0
References: <1307532813-27175-1-git-send-email-peter.maydell@linaro.org>	<4DEF6B2B.7090305@siemens.com>
	<m3y61bvtyj.fsf@blackfin.pond.sub.org>	<4DF0FCDA.5070804@siemens.com>
	<m339ji85o8.fsf@blackfin.pond.sub.org>	<4DF21334.2070204@us.ibm.com>
	<m3hb7xwx4z.fsf@blackfin.pond.sub.org>	<4DF23BB7.9050606@us.ibm.com>
	<4DF4F371.90003@redhat.com>	<4DF511B6.5000005@us.ibm.com>	<BANLkTi=j6B=UrYp=bQ62=JUOiSbgkLYXNw@mail.gmail.com>	<4DF76041.1000007@codemonkey.ws>
	<BANLkTimU6kg=9GXkwCnQ_UZ1rr1CM1TBiw@mail.gmail.com>
In-Reply-To: <BANLkTimU6kg=9GXkwCnQ_UZ1rr1CM1TBiw@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] [PATCH RFC 0/3] basic support for composing sysbus
 devices
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: Blue Swirl <blauwirbel@gmail.com>
Cc: Peter Maydell <peter.maydell@linaro.org>, =?UTF-8?B?SnVoYSBSaWloaW3DpA==?= =?UTF-8?B?a2k=?= <juha.riihimaki@nokia.com>, "patches@linaro.org" <patches@linaro.org>, Jan Kiszka <jan.kiszka@siemens.com>, "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>, Markus Armbruster <armbru@redhat.com>, Avi Kivity <avi@redhat.com>, Paul Brook <paul@codesourcery.com>

On 06/15/2011 01:56 PM, Blue Swirl wrote:
> On Tue, Jun 14, 2011 at 4:21 PM, Anthony Liguori<anthony@codemonkey.ws>  wrote:
>>
>> Which suggests that we really need to move away from declarative device
>> definitions.  It makes it hard to have variable numbers of properties.
>
> I'd suppose the number of slots could be fixed. Then the declaration could be
>        DEFINE_PROP_SOCKETS(I440FXState, slot, 32),

That's fine for something like a PCI controller, but for something like 
a multiport network card, it's really desirable to be able to specify 
the number of ports as part of the config.  IOW:

  -device virtio-net-pci,ports=8,netdev[0]=tap0,netdev[1]=tap1,...

>> In this case, piix3 would be defined as:
>>
>> struct I440FXState {
>>     PIIX3 piix3;
>>     PCIDevice slots[32];
>> };
>>
>> Which suggests we need an initfn to do the following:
>>
>> void i440fx_initfn(...) {
>>    qdev_init_inplace(&dev->piix3, "PIIX3");
>>    dev->slot[1] =&dev->piix3->bus;
>> }
>>
>> This gets hard to do well in C though.  I'm not sure how we could make
>> DEFINE_PROP_PLUG/SOCKET type safe.
>
> DEFINE_PROP_PCI_SOCKET()?

Yeah, that's why I said, "hard to do well".  It makes it very hard to 
add new socket types.

Regards,

Anthony Liguori

>