From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:38188) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UG9Ax-0005p3-UD for qemu-devel@nongnu.org; Thu, 14 Mar 2013 10:30:41 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UG9Ao-0006oU-AR for qemu-devel@nongnu.org; Thu, 14 Mar 2013 10:30:35 -0400 Received: from mail-ye0-f182.google.com ([209.85.213.182]:54822) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UG9Ao-0006n8-3a for qemu-devel@nongnu.org; Thu, 14 Mar 2013 10:30:26 -0400 Received: by mail-ye0-f182.google.com with SMTP id r9so393826yen.13 for ; Thu, 14 Mar 2013 07:30:25 -0700 (PDT) Sender: fluxion Date: Thu, 14 Mar 2013 09:28:56 -0500 From: mdroth Message-ID: <20130314142856.GM4005@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> <20130313231836.GA9093@vm> <51412C5B.1000003@linux.vnet.ibm.com> <20130314121849.GJ4005@vm> <5141D302.3050607@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5141D302.3050607@linux.vnet.ibm.com> Subject: Re: [Qemu-devel] [PATCH 5/9] qapi_sized_buffer List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Berger Cc: Joel Schopp , qemu-devel@nongnu.org, Michael Tsirkin On Thu, Mar 14, 2013 at 09:39:14AM -0400, Stefan Berger wrote: > On 03/14/2013 08:18 AM, mdroth wrote: > >On Wed, Mar 13, 2013 at 09:48:11PM -0400, Stefan Berger wrote: > >>On 03/13/2013 07:18 PM, mdroth wrote: > >>>On Wed, Mar 13, 2013 at 06:00:24PM -0400, Stefan Berger wrote: > >>>>On 03/13/2013 04:52 PM, mdroth wrote: > >>>> > >>>Visitors don't have any knowledge of the data structures they're visiting > >>>outside of what we tell them via the visit_*() API. > >>> > >>>[...] > >>> > >>>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 > >>Given this example above, I think we will need the sized buffer. The > >>sized buffer targets binary arrays and their encoding. If I was to > >>encode an 'unsigned char[n]' (e.g., n=200) using n, or n/2 or n/4 > >>loops like above breaking it apart in u8, u16 or u32 respectively I > >>think this would 'not bed good' also considering the 2 bytes for tag > >>and length being added by ASN.1 for every such datatype > >>(u8,u16,u32). The sized buffer allows you to for example take a > >>memory page and write it out in one chunk adding a few bytes of > >>ASN.1 'decoration' around the actual data. > >You could do it with this interface as well actually. The Visitor will > >need to maintain some internal state to differentiate what it does with > >subsequent visit_type*/visit_next_carray/visit_end_carry. There's no > >reason it couldn't also track the elem size so it could tag a buffer > >"en masse" when visit_end_carray() gets called. > > It depends on what you pass into visit_start_carray. In your case if > you pass in ComplexType you would pass in a sizeof(ComplexType) for > the size of each element presumably. The problem is now you have > char *foo, a string pointer, hanging off of this structure. How > would you handle that? Serializing ComplexType's foo and pointer > obviously won't do it. Why not? visit_type_ComplexType() knows how to deal with the individual fields, including the string pointer. I'm not sure what's at issue here. In this case the handling for ComplexType would look something like: visit_type_Complex: visit_start_struct visit_type_uin32 //foo visit_type_str //bar visit_end_struct Granted, strings are easier to deal with. If char * was instead a plain old uint8_t*, we'd need a nested call to start_carray for each element. in this case it would look something like: visit_type_Complex: visit_start_struct visit_type_uin32 //foo field visit_start_carray //bar field for (i = 0; i < len_of_bar; i++): visit_type_uint8 visit_next_carray visit_end_carray visit_end_struct The key is knowing the length. In open coded visitor routines we know this, or where to get it, for routines generated from QAPI schemas we'd a way to tell the code generators how to field the size, or state the size in the schema directly. I had some patches to do this, but we don't have a QAPI user that needs this yet. When we do, visit_*_carray() should be able to handle it, so we should consolidate around that interface since there are a lot of things to consider in the scope of what a visitor implementation may be used for. > would you handle that? Serializing ComplexType's foo and pointer > obviously won't do it. You need to follow the string pointer and > serialize that as well. So we have different use cases here when > wanting to serialize ComplexType versus a plain array with the > carray calls somehow having to figure it out themselves -- how ?? for a plain array we'd just replace visit_type_ComplexType() with visit_type_uint{8,16,32,64} and change loop/elem_size params accordingly. > > Stefan >