From: mdroth <mdroth@linux.vnet.ibm.com>
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>
Subject: Re: [Qemu-devel] [PATCH 5/9] qapi_sized_buffer
Date: Wed, 13 Mar 2013 18:18:36 -0500 [thread overview]
Message-ID: <20130313231836.GA9093@vm> (raw)
In-Reply-To: <5140F6F8.3080101@linux.vnet.ibm.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
>
>
>
next prev parent reply other threads:[~2013-03-13 23:20 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-13 18:56 [Qemu-devel] [PATCH 0/9 v3] Implement and test asn1 ber visitors Joel Schopp
2013-03-13 18:56 ` [Qemu-devel] [PATCH 1/9] qemu-file Joel Schopp
2013-03-13 18:56 ` [Qemu-devel] [PATCH 2/9] qapi_c_arrays.diff Joel Schopp
2013-03-13 19:11 ` Anthony Liguori
2013-03-13 22:54 ` Stefan Berger
2013-03-13 18:56 ` [Qemu-devel] [PATCH 3/9] two new file wrappers Joel Schopp
2013-03-13 21:04 ` Eric Blake
2013-03-14 10:49 ` Stefan Berger
2013-03-13 18:56 ` [Qemu-devel] [PATCH 4/9] qemu_qsb.diff Joel Schopp
2013-03-13 21:11 ` mdroth
2013-03-13 21:28 ` Stefan Berger
2013-03-13 22:41 ` mdroth
2013-03-13 22:47 ` mdroth
2013-03-13 23:11 ` Stefan Berger
2013-03-13 18:56 ` [Qemu-devel] [PATCH 5/9] qapi_sized_buffer Joel Schopp
2013-03-13 20:52 ` mdroth
2013-03-13 22:00 ` Stefan Berger
2013-03-13 23:18 ` mdroth [this message]
2013-03-14 1:48 ` Stefan Berger
2013-03-14 12:18 ` mdroth
2013-03-14 13:39 ` Stefan Berger
2013-03-14 14:28 ` mdroth
2013-03-14 14:51 ` Stefan Berger
2013-03-14 15:11 ` mdroth
2013-03-14 15:24 ` Stefan Berger
2013-03-14 21:06 ` mdroth
2013-03-15 2:05 ` Stefan Berger
2013-03-13 18:56 ` [Qemu-devel] [PATCH 6/9] asn1_output-visitor.diff Joel Schopp
2013-03-13 18:56 ` [Qemu-devel] [PATCH 7/9] asn1_input-visitor.diff Joel Schopp
2013-03-13 18:56 ` [Qemu-devel] [PATCH 8/9] asn1_test_visitor_serialization.diff Joel Schopp
2013-03-13 18:56 ` [Qemu-devel] [PATCH 9/9] update_maintainers.diff Joel Schopp
-- strict thread matches above, loose matches on Subject: below --
2013-03-13 3:09 [Qemu-devel] [PATCH 0/9 v2] Implement and test asn1 ber visitors Joel Schopp
2013-03-13 3:09 ` [Qemu-devel] [PATCH 5/9] qapi_sized_buffer Joel Schopp
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20130313231836.GA9093@vm \
--to=mdroth@linux.vnet.ibm.com \
--cc=jschopp@linux.vnet.ibm.com \
--cc=mst@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=stefanb@linux.vnet.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).