All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: amit.shah@redhat.com, quintela@redhat.com, qemu-devel@nongnu.org,
	mst@redhat.com
Subject: Re: [Qemu-devel] [PATCH] Migration compatibility for serial
Date: Wed, 17 Jun 2015 10:38:30 +0100	[thread overview]
Message-ID: <20150617093830.GC2122@work-vm> (raw)
In-Reply-To: <558134B7.5060603@redhat.com>

* Paolo Bonzini (pbonzini@redhat.com) wrote:
> 
> 
> On 17/06/2015 10:37, Dr. David Alan Gilbert wrote:
> >> > On 16/06/2015 20:54, Dr. David Alan Gilbert (git) wrote:
> >> > > From: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
> >> > > 
> >> > > Older QEMUs dont understand the new (sub)sections that
> >> > > may be generated in the serial device.   Limit their generation
> >> > > to newer machine types.
> >> > > 
> >> > > Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
> > > 
> > > No, please.  Upstream QEMU doesn't want to get into judgement about when
> > > migration quality might be "good enough" that you can drop subsections.
> > 
> > Other people disagree with that statement.
> > Who upstream doesn't want it?
> 
> That's always been the policy as far as I know.  Certainly I don't.
> When we were working on RHEL7, there were quite a few discussions about
> this; I remember Orit Wassermann also was a proponent of the "clean
> slate" approach.

> The problem is that if you want bug compatibility, you also want a point
> (e.g. a major release) where you can start from a clean slate and drop
> all compatibility hacks.  Upstream there is no such point.

It doesn't necessarily have to be a clean slate; the other way to do it is
to have a version cut off, so you don't have any bug-compatibility
prior to a particular version, and then roll that cut off point forward,
much in the same way we do for glib version dependencies.
My flag naming of 'serial_migrate_pre_2_2' at least made it clear
where the line was for that feature.

> It's already hard enough to ensure compatibility of versioned machine
> types, which are static, up to QEMU 0.10 or so; imagine what it would be
> like to guarantee the same for migration six or seven years down the
> line, considering how extremely data-driven migration is.

I agree it's not easy, and indeed this serial fix is just one of a whole
bunch of fixes that are needed.  But if you never try then you never
get any compatibility.

Dave

> 
> Paolo
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK

      reply	other threads:[~2015-06-17  9:38 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-06-16 18:54 [Qemu-devel] [PATCH] Migration compatibility for serial Dr. David Alan Gilbert (git)
2015-06-16 20:49 ` Michael S. Tsirkin
2015-06-17  9:09   ` Dr. David Alan Gilbert
2015-06-17  6:52 ` Markus Armbruster
2015-06-17  6:58   ` Michael S. Tsirkin
2015-06-17  7:11     ` Markus Armbruster
2015-06-17  7:25       ` Michael S. Tsirkin
2015-06-17  7:41 ` Paolo Bonzini
2015-06-17  7:52   ` Michael S. Tsirkin
2015-06-17  8:11     ` Paolo Bonzini
2015-06-17 10:13       ` Michael S. Tsirkin
2015-06-17 10:48         ` Juan Quintela
2015-06-17 10:51           ` Dr. David Alan Gilbert
2015-06-17 10:56             ` Michael S. Tsirkin
2015-06-17 10:59               ` Dr. David Alan Gilbert
2015-06-17 11:36                 ` Michael S. Tsirkin
2015-06-17 10:55           ` Michael S. Tsirkin
2015-06-17 11:33         ` Paolo Bonzini
2015-06-17 11:40           ` Dr. David Alan Gilbert
2015-06-17 11:44             ` Paolo Bonzini
2015-06-17 11:48               ` Michael S. Tsirkin
2015-06-17 12:07               ` Dr. David Alan Gilbert
2015-06-17 12:20                 ` Paolo Bonzini
2015-06-17 14:44                   ` Michael S. Tsirkin
2015-06-17 16:34                     ` Juan Quintela
2015-06-17 16:39                       ` Michael S. Tsirkin
2015-06-17 16:40                         ` Paolo Bonzini
2015-06-17 11:45           ` Michael S. Tsirkin
2015-06-17 11:53             ` Paolo Bonzini
2015-06-17 11:54               ` Michael S. Tsirkin
2015-06-17 11:55                 ` Paolo Bonzini
2015-06-17 11:58                   ` Michael S. Tsirkin
2015-06-17 12:20                     ` Paolo Bonzini
2015-06-17 14:50                       ` Michael S. Tsirkin
2015-06-17 16:16                         ` Paolo Bonzini
2015-06-17 16:34                           ` Michael S. Tsirkin
2015-06-17 16:35                             ` Paolo Bonzini
2015-06-17  9:26     ` Juan Quintela
2015-06-17 10:37       ` Michael S. Tsirkin
2015-06-17  8:37   ` Dr. David Alan Gilbert
2015-06-17  8:49     ` Paolo Bonzini
2015-06-17  9:38       ` Dr. David Alan Gilbert [this message]

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=20150617093830.GC2122@work-vm \
    --to=dgilbert@redhat.com \
    --cc=amit.shah@redhat.com \
    --cc=mst@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=quintela@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.