From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:35294) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z59nq-0007CW-GR for qemu-devel@nongnu.org; Wed, 17 Jun 2015 05:38:39 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z59nn-00072f-Qk for qemu-devel@nongnu.org; Wed, 17 Jun 2015 05:38:38 -0400 Received: from mx1.redhat.com ([209.132.183.28]:46296) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z59nn-00072Z-L0 for qemu-devel@nongnu.org; Wed, 17 Jun 2015 05:38:35 -0400 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (Postfix) with ESMTPS id E6CB32D4519 for ; Wed, 17 Jun 2015 09:38:34 +0000 (UTC) Date: Wed, 17 Jun 2015 10:38:30 +0100 From: "Dr. David Alan Gilbert" Message-ID: <20150617093830.GC2122@work-vm> References: <1434480849-23093-1-git-send-email-dgilbert@redhat.com> <558124BD.8010807@redhat.com> <20150617083721.GA2122@work-vm> <558134B7.5060603@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <558134B7.5060603@redhat.com> Subject: Re: [Qemu-devel] [PATCH] Migration compatibility for serial List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: amit.shah@redhat.com, quintela@redhat.com, qemu-devel@nongnu.org, mst@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" > >> > > > >> > > 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 > > > > > > 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