From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:46774) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RAiIG-0001Vv-JV for qemu-devel@nongnu.org; Mon, 03 Oct 2011 09:10:53 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RAiIE-0005EF-Lm for qemu-devel@nongnu.org; Mon, 03 Oct 2011 09:10:52 -0400 Received: from e9.ny.us.ibm.com ([32.97.182.139]:35516) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RAiIE-0005Dx-IB for qemu-devel@nongnu.org; Mon, 03 Oct 2011 09:10:50 -0400 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e9.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id p93CYrUh020697 for ; Mon, 3 Oct 2011 08:34:53 -0400 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p93DAWGs194886 for ; Mon, 3 Oct 2011 09:10:33 -0400 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p93DAPvg004496 for ; Mon, 3 Oct 2011 07:10:30 -0600 Message-ID: <4E89B43B.4080000@linux.vnet.ibm.com> Date: Mon, 03 Oct 2011 09:10:19 -0400 From: Stefan Berger MIME-Version: 1.0 References: <1316443309-23843-1-git-send-email-mdroth@linux.vnet.ibm.com> <4E88C7DB.9090105@linux.vnet.ibm.com> <20111002210802.GC8072@redhat.com> <4E89B0D4.3090203@us.ibm.com> In-Reply-To: <4E89B0D4.3090203@us.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: Anthony Liguori Cc: qemu-devel@nongnu.org, aliguori@linux.vnet.ibm.com, Michael Roth , "Michael S. Tsirkin" On 10/03/2011 08:55 AM, Anthony Liguori wrote: > On 10/02/2011 04:08 PM, Michael S. Tsirkin wrote: >> On Sun, Oct 02, 2011 at 04:21:47PM -0400, Stefan Berger wrote: >>> >>>> 4) Implement the BERVisitor and make this the default migration >>>> protocol. >>>> >>>> Most of the work will be in 1), though with the implementation in >>>> this series we should be able to do it incrementally. I'm not sure >>>> if the best approach is doing the mechanical phase 1 conversion, >>>> then doing phase 2 sometime after 4), doing phase 1 + 2 as part of >>>> 1), or just doing VMState conversions which gives basically the >>>> same capabilities as phase 1 + 2. >>>> >>>> Thoughts? >>> Is anyone working on this? If not I may give it a shot (tomorrow++) >>> for at least some of the primitives... for enabling vNVRAM metadata >>> of course. Indefinite length encoding of constructed data types I >>> suppose won't be used otherwise the visitor interface seems wrong >>> for parsing and skipping of extra data towards the end of a >>> structure if version n wrote the stream and appended some of its >>> version n data and now version m< n is trying to read the struct >>> and needs to skip the version [m+1, n ] data fields ... in that case >>> the de-serialization of the stream should probably be stream-driven >>> rather than structure-driven. >>> >>> Stefan >> >> Yes I've been struggling with that exactly. >> Anthony, any thoughts? > > It just depends on how you write your visitor. If you used sequences, > you'd probably do something like this: > > start_struct -> > check for sequence tag, push starting offset and size onto stack > increment offset to next tag > > type_int (et al) -> > check for explicit type, parse data > increment offset to next tag > > end_struct -> > pop starting offset and size to temp variables > set offset to starting offset + size > > This is roughly how the QMP input marshaller works FWIW. > I am doing that. Indefinite length encoding *would* be a problem because you cannot push the size onto the stack so that you could skip to the end of the structure. Stefan