qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH RFC 0/3] basic support for composing sysbus devi


From: Blue Swirl
Subject: Re: [Qemu-devel] [PATCH RFC 0/3] basic support for composing sysbus devices
Date: Wed, 15 Jun 2011 23:20:45 +0300

On Wed, Jun 15, 2011 at 11:00 PM, Anthony Liguori <address@hidden> wrote:
> On 06/15/2011 01:56 PM, Blue Swirl wrote:
>>
>> On Tue, Jun 14, 2011 at 4:21 PM, Anthony Liguori<address@hidden>
>>  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 the PCI cases, I'd use the maximum allowed by PCI.

>>> 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.

PCI, USB, IDE, SCSI, SBus, what else? APICBus? I2C? 8 socket types
ought to be enough for anybody.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]