Re: [Qemu-devel] [PATCH v2 0/5] q35: Remove old machines and unused compat code

[Michael S. Tsirkin]

On Thu, Feb 04, 2016 at 03:16:17PM -0200, Eduardo Habkost wrote:
> 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.
> > 

I agree with the conclusion for option B.  But I think the correct
solution is not A, it is to analyse changes, maybe even test, and show
that nothing bad can happen.

Because A suffers from exactly the same problem if people just blindly
switch to a new machine type.

> -- 
> Eduardo