On Thu, Feb 04, 2016 at 06:01:50PM +0200, Michael S. Tsirkin wrote: > On Sat, Jan 23, 2016 at 02:02:08PM -0200, Eduardo Habkost wrote: > > This is another attempt to remove old q35 machine code. Now I am > > also removing unused compat code to demonstrate the benefit of > > throwing away the old code that nobody uses. > > The same thing I said applies - we don't know that nobody uses old q35 > machine types. > We do know we don't need to migrate to/from them, > so we can drop compat code. > But please add aliases so people can still start these machines.
If people use them, they can easily update their configurations. I will copy and paste the reply Markus sent 4 months ago below. On Mon, Sep 14, 2015 at 09:18:47AM +0200, Markus Armbruster wrote: > We've been through this before, but we can go through it once more. > Choices: > > A. Remove old machine type > > A guest using it can't be started. Easy to understand on the host. > An error message advising to switch to a newer machine type would be > a nice touch. > > This is a clean break in backward compatibility. To be mentioned in > release notes, obviously. > > B. Change old machine type in a guest-visible way > > Depending on the nature of the change and the guest, a guest using it > either doesn't notice, copes with it successfully, or fails in > guest-specific ways. If the latter, the failure can be "guest > hangs", which is much harder to figure out than A. > > Unless we can *demonstrate* that nothing bad happens for all the > guests people actually use with the old machine types, this is a > different kind of backward compatibility break. > > Demonstrating this is feels infeasible to me, but you're welcome to > try. > > I could call the difference between the two a tradeoff, but since we've > been through this before, I'll be more blunt: choosing B robs Peter (the > guy with guests where badness happens) to pay Paul (the guy with guests > that cope). Paul is saved the inconvenience of having to read release > notes or his logs, and change machine types. Peter pays for that with > figuring out WTF his guests are doing now. > > As a user, I'd pick a clean break in backward compatibility over a hack > that preserves effective compatibility when it works, but breaks it > uncleanly when it doesn't. > > As a developer, I'm insisting on it. > > So, if you want B, the onus is on *you* to show us why nothing bad will > happen. > -- Eduardo
