On 06/12/2011 10:21 PM, Anthony Liguori wrote:
It's perfectly fine to have a type called PCIBus that I440FX extends,
but qdev shouldn't have explicit knowledge of something called a "bus"
IMHO. Doing this forces a limited mechanism of connecting devices
because it creates an artificial tree (by implying a parent/child
relationship). It makes composition difficult if not impossible.
I think qdev buses are useful as long as they don't enforce their
interfaces. That is, a qdev that is a child of a qbus has access to the
qbus's interfaces, but also access to other stuff.
I see two independent data structures. The first is the "instantiation
tree".
The instantiation tree may look like this:
+-- i440fx
| |
| +-- PIIX3
| | |
| | +-- mc146818a
| | +-- uart
| | +-- DMA
| | +-- keyboard controller
| | +-- (remaining platform ISA devices
| |
| +-- UHCI USB controller
| +-- IDE controller
|
+-- e1000
+-- cirrus-vga
+-- virtio-balloon-pci
+-- IDE disk0
Instantiating i440fx makes a bunch of default stuff. This is
composition. Everything else requires explicit instantiation. This is,
strictly speaking, the parent/child relationships. If you destroy
i440fx, all of it's children have to also go away (by definition).
Nothing about bus relationship is implied here. Even if i440fx exposes
a PCI bus, the PIIX3 is a child of i440fx even though e1000 is not
(even if they're both PCI devices).
I bus/device relationship is not imposed, but may hold for some of the
devices (but not others).
Another example of aggregation is PCI slots and functions. A PCI device
is composed of multiple functions that can be hotplugged as one, and
share parts of the address. But there is no "slot/function bus" involved.