From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([140.186.70.92]:59949)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <mst@redhat.com>) id 1RAiaX-000102-47
	for qemu-devel@nongnu.org; Mon, 03 Oct 2011 09:29:48 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <mst@redhat.com>) id 1RAiaP-0000Qm-Uk
	for qemu-devel@nongnu.org; Mon, 03 Oct 2011 09:29:45 -0400
Received: from mx1.redhat.com ([209.132.183.28]:60743)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <mst@redhat.com>) id 1RAiaP-0000QX-NU
	for qemu-devel@nongnu.org; Mon, 03 Oct 2011 09:29:37 -0400
Date: Mon, 3 Oct 2011 15:30:41 +0200
From: "Michael S. Tsirkin" <mst@redhat.com>
Message-ID: <20111003133040.GC18920@redhat.com>
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>
	<4E89B43B.4080000@linux.vnet.ibm.com> <4E89B627.7010008@us.ibm.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4E89B627.7010008@us.ibm.com>
Subject: Re: [Qemu-devel] [RFC] New Migration Protocol using Visitor
	Interface
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Anthony Liguori <aliguori@us.ibm.com>
Cc: qemu-devel@nongnu.org, aliguori@linux.vnet.ibm.com, Michael Roth <mdroth@linux.vnet.ibm.com>, Stefan Berger <stefanb@linux.vnet.ibm.com>

On Mon, Oct 03, 2011 at 08:18:31AM -0500, Anthony Liguori wrote:
> On 10/03/2011 08:10 AM, Stefan Berger wrote:
> >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.
> 
> For an indefinite length encoding, you just have to keep reading the
> stream at end_struct until you hit the canary tag ignoring anything
> you encounter.
> 
> Regards,
> 
> Anthony Liguori

That's not exactly right: one indefinite length encoding can be nested
within the other. So what we must do is keep reading, read out,
decode and skip regular length encodings, and count the
nesting of indefinite length encodings. When we see bit 7 set,
we increase nesting. When we see end of content, we descrease nesting.
Stop when nesting reaches 0.

-- 
MST