From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:56462) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RBGrD-0003BP-Ce for qemu-devel@nongnu.org; Tue, 04 Oct 2011 22:05:16 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RBGrC-00009d-1i for qemu-devel@nongnu.org; Tue, 04 Oct 2011 22:05:15 -0400 Received: from e2.ny.us.ibm.com ([32.97.182.142]:49868) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RBGrB-00009T-NN for qemu-devel@nongnu.org; Tue, 04 Oct 2011 22:05:13 -0400 Received: from /spool/local by us.ibm.com with XMail ESMTP for from ; Tue, 4 Oct 2011 22:05:09 -0400 Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay06.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p95253Yg1585154 for ; Tue, 4 Oct 2011 22:05:05 -0400 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p95252RG004457 for ; Tue, 4 Oct 2011 23:05:03 -0300 Message-ID: <4E8BBB4E.5000907@linux.vnet.ibm.com> Date: Tue, 04 Oct 2011 22:05:02 -0400 From: Stefan Berger MIME-Version: 1.0 References: <1316443309-23843-1-git-send-email-mdroth@linux.vnet.ibm.com> <20111003064653.GA15380@redhat.com> <4E89AFB4.8000103@us.ibm.com> <20111003132445.GB18920@redhat.com> <4E89BC1A.30208@codemonkey.ws> In-Reply-To: <4E89BC1A.30208@codemonkey.ws> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC] New Migration Protocol using Visitor Interface List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: qemu-devel@nongnu.org, aliguori@linux.vnet.ibm.com, Anthony Liguori , Michael Roth , "Michael S. Tsirkin" On 10/03/2011 09:43 AM, Anthony Liguori wrote: > On 10/03/2011 08:24 AM, Michael S. Tsirkin wrote: >> On Mon, Oct 03, 2011 at 07:51:00AM -0500, Anthony Liguori wrote: >>>> Here are some suggestions: >>>> >>>> - Let's make the protocol be BER directly. >>>> As a first step, use a single octet string for >>>> the whole of data. Next, start splitting this up. >>> >>> This can't be done without breaking the old style migration >>> protocol. I don't have a problem with that but I do have a problem >>> with repeatedly breaking migration protocol. >> >> As long as this is within a release cycle, is this a real problem? > > I think if we try to fit it within a release we'll either end up with > a 2 year long release or a half-broken conversion. > > I'd rather buy ourselves time by supporting both formats. That way we > can remove the old format when we're satisfied with the ASN.1 encoding. Hm, if backwards compatibility is what we want to achieve (migrating from Qemu 1.1 to Qemu 1.0) then at least the ASN.1 decoder / encoder should be all done in 1.0, no? Otherwise what would it mean to if 1.0 just skipped types 1.1 sends and doesn't understand? > There are multiple things to consider with compatibility: > > 1) Creating compatible device models. This is a qdev problem and > can't be solved in the protocol. > > 2) Ensuring we are sending all the data we need to. I think we solve > this problem by autogenerating Visitors from the C definitions of the > device structures. > I would have thought that we would write a function that takes the VMStateDescription as an argument and write ASN.1 BER or CER comprising: - a header containing the version of the device data - the minimum version required to read the device data - walk the array of VMStateFields and encode the the device data and similarly a function for walking the fields for decoding of each device state. So at least I am surprised to hear 'autogeneration' for this particular case... Stefan