On Wed, Jun 17, 2015 at 01:34:33PM -0400, Don Slutz wrote: > On 06/17/15 13:25, Paolo Bonzini wrote: > > > > > > 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. > > > > Either way I can avoid the device creation... Unless I hear otherwise I > will go the global way. Since the default would be no, should I also > make the default =yes for the 2.4 pc? > > -Don Slutz > > -Don Slutz
Can you use -device vmport_rpc, and avoid adding code to the default pc? > > Paolo > >
