From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:37735) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RBR09-0007kr-E7 for qemu-devel@nongnu.org; Wed, 05 Oct 2011 08:55:13 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RBR05-0005Od-Dk for qemu-devel@nongnu.org; Wed, 05 Oct 2011 08:55:09 -0400 Received: from e31.co.us.ibm.com ([32.97.110.149]:58320) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RBR05-0005O1-4v for qemu-devel@nongnu.org; Wed, 05 Oct 2011 08:55:05 -0400 Received: from /spool/local by us.ibm.com with XMail ESMTP for from ; Wed, 5 Oct 2011 06:55:01 -0600 Received: from d03av06.boulder.ibm.com (d03av06.boulder.ibm.com [9.17.195.245]) by d03relay02.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p95CsNuf130086 for ; Wed, 5 Oct 2011 06:54:24 -0600 Received: from d03av06.boulder.ibm.com (loopback [127.0.0.1]) by d03av06.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p95CsNmY001339 for ; Wed, 5 Oct 2011 06:54:23 -0600 Message-ID: <4E8C537D.2090007@us.ibm.com> Date: Wed, 05 Oct 2011 07:54:21 -0500 From: Anthony Liguori 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> <4E8BBB4E.5000907@linux.vnet.ibm.com> In-Reply-To: <4E8BBB4E.5000907@linux.vnet.ibm.com> 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: Stefan Berger Cc: qemu-devel@nongnu.org, aliguori@linux.vnet.ibm.com, Michael Roth , "Michael S. Tsirkin" On 10/04/2011 09:05 PM, Stefan Berger wrote: > 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? Before we introduce ASN1, we ought to introduce migration capabilities. Migration capabilities would be used to negotation ASN.1 over the wire. That means that 1.1 would use the existing protocol to talk to 1.0. >> 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 Sort of. You modify VMStateInfo to accept a visitor and name parameter in load and put. Then you write an ASN.1 BER Visitor and pass that visitor to VMStateInfo->load/put. Regards, Anthony Liguori > > 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