From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:46095) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UBY9j-0004rB-2G for qemu-devel@nongnu.org; Fri, 01 Mar 2013 17:10:20 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UBY9h-0003j8-8H for qemu-devel@nongnu.org; Fri, 01 Mar 2013 17:10:19 -0500 Received: from e8.ny.us.ibm.com ([32.97.182.138]:52380) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UBY9h-0003iW-3u for qemu-devel@nongnu.org; Fri, 01 Mar 2013 17:10:17 -0500 Received: from /spool/local by e8.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Fri, 1 Mar 2013 17:10:14 -0500 Received: from d01relay06.pok.ibm.com (d01relay06.pok.ibm.com [9.56.227.116]) by d01dlp03.pok.ibm.com (Postfix) with ESMTP id 4C279C90025 for ; Fri, 1 Mar 2013 17:10:04 -0500 (EST) Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay06.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id r21MA4ni29884566 for ; Fri, 1 Mar 2013 17:10:04 -0500 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id r21MA3YX025777 for ; Fri, 1 Mar 2013 17:10:03 -0500 Message-ID: <5131273B.8010104@linux.vnet.ibm.com> Date: Fri, 01 Mar 2013 17:10:03 -0500 From: Stefan Berger MIME-Version: 1.0 References: <20130226230627.432353713@linux.vnet.ibm.com> <20130227225748.GD1748@vm> <512E95BD.9040302@linux.vnet.ibm.com> <20130227235230.GA21850@vm> In-Reply-To: <20130227235230.GA21850@vm> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 2/3] asn1 ber visitors List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: mdroth Cc: jschopp@linux.vnet.ibm.com, "Michael S. Tsirkin" , qemu-devel@nongnu.org, =?ISO-8859-1?Q?Andreas_F=E4rber?= On 02/27/2013 06:52 PM, mdroth wrote: > On Wed, Feb 27, 2013 at 06:24:45PM -0500, Stefan Berger wrote: > > This is actually exactly what test-visitor-serialization.c does. It > feeds various normal/corner cases of visit_type_* into your output > visitor, takes that output and feeds it back into the input visitor, > then validates it against the original input. Just need to create > a SerializeOps implementation to drive your visitor and plug it > in like the others. > > Just doing that would be a good start at least, but it would be really > nice to validate the encoding against some other reference implementation. > Have you looked into libsnacc? It seems to be the most readilly > available library. I wouldn't make it a formal build requirement, but it > would be nice to be able to execute test cases that use it if it's > present. I have seen the documentation about libtasn1 http://www.gnu.org/software/libtasn1/ I am not familiar with libsnacc. > > Even failing that, I personally wouldn't even mind just generating an > encoded blob outside the tree, and then checking that it along with the > textual description and steps to generate it, then validating the > visitors against it. It's not too far off from our "hand-written" JSON > to test the QMP visitors. Ok, so we will do that. It will lock our implementation into generating one type of byte stream, which is good. > > I don't think we have any reasonable assurance that our implementation > is correct otherwise. Well, at least the round-tripping of data written with the output visitors and then read again with the input visitors plus following verification gives you some aspects of correct implementation. One design choice I have made while implementing the encoder/decoder was that integers will always be encoded in their respective size, meaning that independent of value of a 32bit integer it will be represented in 4 bytes. This may, following ITU X.690 spec, be a application-specific or private encoding of an integer. See the spec section 8.3 for that. http://www.itu.int/ITU-T/studygroups/com17/languages/X.690-0207.pdf I have done this to avoid deflating and inflating blobs when used in NVRAM later on so that we can use the input visitor to find a blob with a given name and then switch to the output visitor and replace that blob with a new value. If such a blob would deflate/inflate because of the value of an integer all consecutive blobs in the NVRAM would have to be moved to maintain readability of the ASN.1 stream. The NVRAM will be one long ASN.1 stream in a block device. However, we could give output visitor users control over how the integers are to be encoded (following standard versus fixed-width) by passing a flag when instantiating the output visitor. Regards, Stefan