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).
That said, there absolutely should be the following paths:
/i440fx/IDE controller/primary/master -> IDE disk0
/i440fx/slot3 -> cirrus-vga
The expression of bus should just be a bidirectional path (when that
makes sense). IOW:
/i440fx/slot3 -> cirrus-vga
/cirrus-vga/bus -> i440fx
There, of course, can be all sorts of crazy paths through the graph.
The following should be valid:
/i440fx/slot2 -> IDE controller
/cirrus-vga/bus/slot2/primary/master
But separating out hw paths from instantiation tree has some nice
characteristics. The instantiation tree is the obvious place to
implement live migration whereas reset would probably walk device paths.