On Wed, Jun 17, 2015 at 07:14:24PM +0200, Paolo Bonzini wrote: > > > On 17/06/2015 19:03, Don Slutz wrote: > > On 06/17/15 12: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. > >> > >>> 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. > >> > > > > My take on this is that Michael would like me to have a vmport_rpc=on > > option, just like vmport=on (which already exists). With a default of off. > > It wouldn't be enough, because dc->vmsd would be non-NULL anyway.
For which device class? > (But yes, that option would be a good thing anyway). > > Paolo