On Mon, Mar 22, 2010 at 08:16:01PM -0500, Anthony Liguori wrote: > On 03/22/2010 07:49 PM, Paul Brook wrote: >>> 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. >> > > Right. The only real challenge is dealing with legacy save/restore and > command line syntax. For save/restore, we can possibly have a dummy > device that can split the VirtioPCI device state from the virtio device > states and do the right thing. > > I'm not sure what we should do for command line syntax. We can keep > -drive working as is. Do we need to support -device based creation? I > don't think we've really considered what to do in a situation like this. > > Regards, > > Anthony Liguori
If we need to change command line because of an implementation change, IMO something is wrong with the design. Users shouldn't care about non-existent virtio bus. >> >> >>> - 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 >> >> >>