From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:51683) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UG8NQ-0007vL-QH for qemu-devel@nongnu.org; Thu, 14 Mar 2013 09:39:31 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UG8NL-0004jl-AZ for qemu-devel@nongnu.org; Thu, 14 Mar 2013 09:39:24 -0400 Received: from e8.ny.us.ibm.com ([32.97.182.138]:59583) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UG8NL-0004jg-6V for qemu-devel@nongnu.org; Thu, 14 Mar 2013 09:39:19 -0400 Received: from /spool/local by e8.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 14 Mar 2013 09:39:18 -0400 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by d01dlp03.pok.ibm.com (Postfix) with ESMTP id 187E7C90050 for ; Thu, 14 Mar 2013 09:39:15 -0400 (EDT) Received: from d01av05.pok.ibm.com (d01av05.pok.ibm.com [9.56.224.195]) by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id r2EDdE1b258682 for ; Thu, 14 Mar 2013 09:39:14 -0400 Received: from d01av05.pok.ibm.com (loopback [127.0.0.1]) by d01av05.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id r2EDdEFd026320 for ; Thu, 14 Mar 2013 09:39:14 -0400 Message-ID: <5141D302.3050607@linux.vnet.ibm.com> Date: Thu, 14 Mar 2013 09:39:14 -0400 From: Stefan Berger MIME-Version: 1.0 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> In-Reply-To: <20130314121849.GJ4005@vm> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 5/9] qapi_sized_buffer List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: mdroth Cc: Joel Schopp , qemu-devel@nongnu.org, Michael Tsirkin 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. 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 ?? Stefan