On 17/06/2015 19:14, 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. > > (But yes, that option would be a good thing anyway).
Even better would be to have a "-global vmport.rpc=no" option. It would be simpler to disable it in existing machine types. Paolo
