On 17/06/2015 18:29, Michael S. Tsirkin wrote: > On Wed, Jun 17, 2015 at 06:17:19PM +0200, Paolo Bonzini wrote: >> >> >> On 17/06/2015 16:29, Michael S. Tsirkin wrote: >>> On Wed, Jun 17, 2015 at 04:27:13PM +0200, Paolo Bonzini wrote: >>>> >>>> >>>> On 17/06/2015 16:18, Michael S. Tsirkin wrote: >>>>>>> Yes, that's what was done for parallel and pcspk as well. There's no >>>>>>> infrastructure to avoid it. >>>>>>> >>>>>>> Paolo >>>>> How do you mean? We have multiple ways to keep devices >>>>> compatible with old versions. >>>>> Set a new property to skip the extra stuff. >>>> >>>> Not if the device didn't have a vmstate at all, unfortunately. >>> >>> Skip creating the device completely for old machine types. >> >> Which device? The vmstate is tied to the same device that has always >> been created. > > Just disable the new functionality. Make it behave in > a compatible way.
Ok. Doesn't solve the fact that the migration stream changes just because dc->vmsd was NULL and now isn't. We cannot add a subsection: there is no toplevel section for it to hang it from. >> we enable this thing by default (why do we?) > > Sigh. There is a very simple way to add a device in qemu: let user > request it with -device. If one does this, one gets to maintain the > resulting mess without bothering with pc maintainers in any way. > > But of course, everyone implementing a new feature feels it's such a > great thing, and completel zero risk, it must be part of the default > machine. Guess what, one then gets to bother with versioning from day 0. > > I don't see what you are saying. Suddenly guest visible > changes within a machine type are ok? Some are. They have always been. For example, the 0xcf9 reset was added without backwards compatibility. Bug fixes are also guest visible. Also, commands are added unconditionally, with only the configuration bits that govern discovery being masked. That's also guest visible if the guest doesn't follow the spec. > So we have a bug, need to fix it, preferably before piling up > more features. The best way imho is for 2.4 to avoid > this device unless requested explicitly. The device is already enabled by default. It grew new functionality (before it was basically just for the mouse). It didn't have state. It now has. Paolo
