From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([208.118.235.92]:50971)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <flukshun@gmail.com>) id 1UFuyD-0003ro-S1
	for qemu-devel@nongnu.org; Wed, 13 Mar 2013 19:20:30 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <flukshun@gmail.com>) id 1UFuyC-0000O9-QV
	for qemu-devel@nongnu.org; Wed, 13 Mar 2013 19:20:29 -0400
Received: from mail-yh0-x235.google.com ([2607:f8b0:4002:c01::235]:63715)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <flukshun@gmail.com>) id 1UFuyC-0000O5-Ll
	for qemu-devel@nongnu.org; Wed, 13 Mar 2013 19:20:28 -0400
Received: by mail-yh0-f53.google.com with SMTP id q3so281973yhf.12
	for <qemu-devel@nongnu.org>; Wed, 13 Mar 2013 16:20:28 -0700 (PDT)
Sender: fluxion <flukshun@gmail.com>
Date: Wed, 13 Mar 2013 18:18:36 -0500
From: mdroth <mdroth@linux.vnet.ibm.com>
Message-ID: <20130313231836.GA9093@vm>
References: <1363200988-17865-1-git-send-email-jschopp@linux.vnet.ibm.com>
	<1363200988-17865-6-git-send-email-jschopp@linux.vnet.ibm.com>
	<20130313205200.GA6188@vm> <5140F6F8.3080101@linux.vnet.ibm.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <5140F6F8.3080101@linux.vnet.ibm.com>
Subject: Re: [Qemu-devel] [PATCH 5/9] qapi_sized_buffer
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: Stefan Berger <stefanb@linux.vnet.ibm.com>
Cc: Joel Schopp <jschopp@linux.vnet.ibm.com>, qemu-devel@nongnu.org, Michael Tsirkin <mst@redhat.com>

On Wed, Mar 13, 2013 at 06:00:24PM -0400, Stefan Berger wrote:
> On 03/13/2013 04:52 PM, mdroth wrote:
> >On Wed, Mar 13, 2013 at 01:56:24PM -0500, Joel Schopp wrote:
> >>Add a sized buffer interface to qapi.
> >Isn't this just a special case of the visit_*_carray() interfaces? We
> >should avoid new interfaces if possible, since it adds to feature
> >disparities between visitor implementations.
> 
> Yes, it's a special case and carray seems more general.
> However, I don't understand the interface of carray. It has a
> start_carray with all parameters given, then a next_carray and an
> end_carray. Why do we need multiple calls if one call (start_carray)
> could be used to serialize all the data already?

Visitors don't have any knowledge of the data structures they're visiting
outside of what we tell them via the visit_*() API.

For output, visit_start_carray() only provides enough information to
instruct a visitor on how to calculate the offsets of each element (and
perhaps allocate some memory for it's own internal buffers etc.)

For input, it provides enough to allocate storage, and calculate offsets
to each element it's deserializing into.

As far as what to do with each element, we need to make additional calls
to instruct it.

For example, a visitor for a 16-element array of:

typedef struct ComplexType {
    int32_t foo;
    char *bar;
} ComplexType;

would look something like:

visit_start_carray(v, ...); // instruct visitor how to calculate offsets
for (i = 0; i < 16; i++) {
    visit_type_ComplexType(v, ...) // instruct visitor how to handle elem
    visit_next_carray(v, ...); // instruct visitor to move to next offset
}
visit_end_carray(v, ...); // instruct visitor to finalize array

> 
> Regards,
>     Stefan
> 
> 
>