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. > 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. > >>> this seems like a big deal ... > >> > >> The PC speaker device is also enabled by default. > > > > This is historical, isn't it? > > Yes, but it has broken 2.3->2.2 migration. > > Let's just stop fighting windmills. > > Paolo I don't see what you are saying. Suddenly guest visible changes within a machine type are ok? 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. -- MST
