[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH 2/3] asn1 ber visitors
From: |
Stefan Berger |
Subject: |
Re: [Qemu-devel] [PATCH 2/3] asn1 ber visitors |
Date: |
Fri, 01 Mar 2013 17:10:03 -0500 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120911 Thunderbird/15.0.1 |
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
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- Re: [Qemu-devel] [PATCH 2/3] asn1 ber visitors,
Stefan Berger <=