On Tue, Mar 23, 2010 at 11:40:46AM +0000, Paul Brook wrote: > > > 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. > > > > 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. > > I don't find this argument convincing. If we need to change the > internal structure of a machine, then users who manipulate the machine > configuration are going to have to compensate for this. > This kind of change is pretty much unavoidable when we get the device > model wrong.
I am yet to see why the model is wrong. virtio devices on pci bus and on s390 bus are different virtual hardware devices. There's no emulated bus. This is not much different from e100 - it can emulate tens of device variants - e100 bus? Anyway, people really want to share implementation and want to do this by means of a bus, ok, but there is nothing here that users care about. And if we let implermentation leak out to command line, we will have compat problems down the line. > The best we can realistically do is avoid making these > changes on a stable branch, and arrange for outdated configs to be > rejected rather than silently doing the wrong thing. > > Paul Practically speaking, we are bound to change internal representation in the future, and breaking scripts, management tools, documentation and simple user habits with each such change would be very bad. -- MST
