Re: [Qemu-devel] [PATCH 2/3] asn1 ber visitors

Re: [Qemu-devel] [PATCH 2/3] asn1 ber visitors

[Stefan Berger]

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