qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Daniel P. Berrange" <berrange@redhat.com>
To: Thomas Huth <thuth@redhat.com>
Cc: qemu-devel@nongnu.org, Richard Henderson <rth@twiddle.net>,
	Eduardo Habkost <ehabkost@redhat.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	kraxel@redhat.com
Subject: Re: [Qemu-devel] [PATCH] hw/i386: Deprecate the machines pc-0.10 to pc-0.15
Date: Wed, 10 May 2017 10:08:41 +0100	[thread overview]
Message-ID: <20170510090841.GF31558@redhat.com> (raw)
In-Reply-To: <1494398933-8366-1-git-send-email-thuth@redhat.com>

On Wed, May 10, 2017 at 08:48:53AM +0200, Thomas Huth wrote:
> We don't want to carry along old machine types forever. If we are able to
> remove the pc machines up to 0.13 one day for example, this would allow
> us to eventually kill the code for rombar=0 (i.e. where QEMU copies ROM
> BARs directly to low memory). So let's start with a deprecation message
> for the old 0.xx machine types so that the (hopefully) few users of these
> old systems start switching over to newer machine types instead.
> 
> Signed-off-by: Thomas Huth <thuth@redhat.com>
> ---
>  Note: I've decided to print the warning for all pc-0.* machine types,
>  but that of course doesn't mean that we also have to remove them all at
>  once when we decide to finally really remove some. We could then also
>  start by removing 0.10 and 0.11 only, for example (since there should
>  really be no users left for these), or only up to 0.13 (to be able to
>  kill rombar=0), as discussed in the "Deprecating old machine types"
>  mail thread recently.


As a point of reference here are the release dates:

v0.10.0: Mar 2009
v0.11.0: Sep 2009
v0.12.0: Dec 2009
v0.13.0: Oct 2010
v0.14.0: Feb 2011
v0.15.0: Aug 2011
   v1.0: Dec 2011
 v1.1.0: Jun 2012
 v1.2.0: Sep 2012
 v1.3.0: Dec 2012
 v1.4.0: Feb 2013
 v1.5.0: May 2013
 v1.6.0: Aug 2013
 v1.7.0: Nov 2013
 v2.0.0: Apr 2014
 v2.1.0: Aug 2014
 v2.2.0: Dec 2014
 v2.3.0: Apr 2015
 v2.4.0: Aug 2015
 v2.5.0: Dec 2015
 v2.6.0: May 2016
 v2.7.0: Sep 2016
 v2.8.0: Dec 2016
 v2.9.0: Apr 2017

If we deprecate in this release (~Aug/Sep 2017), and kill in the next
release  (Dec 2017), that means our oldest machine type pc-1.0 is still
going to be 6 years, or 18 major releases, old. This raises some questions

  - Do we really think that we still have users with VMs that are
    stuck on a 6 year old machine type from 18 major releases ago ?

  - Is 6 years / 18 major releases going to be our cutoff point for
    machine types going forward ?

  - Do we have any confidence that pc-1.0 in QEMU 2.9.0 really is
    migration compatible with pc-1.0 from QEMU 1.0 ? I'm doubtful
    unless someone can show automated testing results that confirm
    it is compatible.

FYI, I'm in favour of culling old machine types, but I think when we do
this it should not be a one-off ad-hoc culling.

It should be accompanied by changes to the documentation that clearly
state our official support policy for machine type lifetimes, so that
users know what to expect for future releases.

Also unless we're going to get more serious about automated testing to
validate machine type compatibility between *all* previously releases,
I think that 6 years / 18 releases is too long a time to have any
confidence in migration compatibility between versions.

IOW, I think you should be more aggressive in culling old machine types
that this patch is...

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

  reply	other threads:[~2017-05-10  9:08 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-10  6:48 [Qemu-devel] [PATCH] hw/i386: Deprecate the machines pc-0.10 to pc-0.15 Thomas Huth
2017-05-10  9:08 ` Daniel P. Berrange [this message]
2017-05-10 10:05   ` Thomas Huth
2017-05-10 10:31     ` Daniel P. Berrange
2017-05-10 14:47       ` Thomas Huth
2017-05-10 16:15         ` Paolo Bonzini
2017-05-11  7:06           ` Markus Armbruster
2017-05-11  7:21             ` Thomas Huth
2017-05-11  9:30           ` Daniel P. Berrange
2017-05-11 15:10             ` Markus Armbruster
2017-05-12  6:55               ` Thomas Huth
2017-05-10 15:37     ` Markus Armbruster
2017-05-10 15:40       ` Paolo Bonzini
2017-05-10 19:04       ` Dr. David Alan Gilbert
2017-05-11  7:20         ` Markus Armbruster
2017-05-10 14:51   ` Dr. David Alan Gilbert
2017-05-10 15:04     ` Daniel P. Berrange
2017-05-10 15:14       ` Dr. David Alan Gilbert
2017-05-11  7:26         ` Markus Armbruster
2017-05-10 15:05     ` Paolo Bonzini

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170510090841.GF31558@redhat.com \
    --to=berrange@redhat.com \
    --cc=ehabkost@redhat.com \
    --cc=kraxel@redhat.com \
    --cc=mst@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=rth@twiddle.net \
    --cc=thuth@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).