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

[Markus Armbruster]

"Michael S. Tsirkin" <address@hidden> writes:

> 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.

What exactly are you proposing to do?  Who should be doing it?  And what
other work are you willing to sacrifice to get this task done?

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

PEBKAC

Users switch machine types for any number of reasons, good and bad.  You
can't stop the ones switching for bad reasons by keeping some barely
working machine type around forever.