From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:41543) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z592w-0002OO-7W for qemu-devel@nongnu.org; Wed, 17 Jun 2015 04:50:11 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z592q-0005uc-Du for qemu-devel@nongnu.org; Wed, 17 Jun 2015 04:50:10 -0400 Received: from mx1.redhat.com ([209.132.183.28]:51009) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z592q-0005te-9e for qemu-devel@nongnu.org; Wed, 17 Jun 2015 04:50:04 -0400 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (Postfix) with ESMTPS id A88CB35C118 for ; Wed, 17 Jun 2015 08:50:03 +0000 (UTC) Message-ID: <558134B7.5060603@redhat.com> Date: Wed, 17 Jun 2015 10:49:59 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <1434480849-23093-1-git-send-email-dgilbert@redhat.com> <558124BD.8010807@redhat.com> <20150617083721.GA2122@work-vm> In-Reply-To: <20150617083721.GA2122@work-vm> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH] Migration compatibility for serial List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Dr. David Alan Gilbert" Cc: amit.shah@redhat.com, quintela@redhat.com, qemu-devel@nongnu.org, mst@redhat.com 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" >> > >=20 >> > > Older QEMUs dont understand the new (sub)sections that >> > > may be generated in the serial device. Limit their generation >> > > to newer machine types. >> > >=20 >> > > Signed-off-by: Dr. David Alan Gilbert > >=20 > > No, please. Upstream QEMU doesn't want to get into judgement about w= hen > > migration quality might be "good enough" that you can drop subsection= s. >=20 > 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'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. Paolo