Solutions:
- VirtIOPCIBus and hang devices from there (anthony). Why? because
this is a simulated pci bus, we can implement the features that we
need (not full pci) in the three showed architectures. We will have
VirtIOPCIBLock everywhere, and its VirtIOPCIBus implmentation will
hide the details.
This is not how I understood Anthony's proposal.
VirtIOPCIBus makes no sense. The whole reason we have this problem is because
the VirtIO devices can not make any assumptions about the bus they are
connected to.
The key point is that we promote VirtIO devices to nodes in the device tree.
i.e. VirtIODevice descends directly from DeviceState.
Instead of trying to make a single polymorphic hybryd object, split into
separate objects for the component parts. Each host binding (PCI, syborg,
s390, etc.) provides a single VirtIO bridge device. This includes a VirtIOBus,
to which the VirtIODevice is attached.
Most of the code and abstraction layers for this are already there.
We just replace virtio_bind_device with VirtIOBus, add direct registration of
VirtIODevice, and rip out all the crufty old device specific bits from virtio-
pci.c.
- having multiple inheritance is "more natural" to virtio, then we have
to change all the system to be able to allow multiple inherintance,
even if it is more complex, and nothing else uses/needs it (mst).
I'm not convinced multiple inheritance solves the real problem, much less that
it is worthwhile.
Paul