asn1: Update README.temlate
This commit is contained in:
@@ -11,15 +11,25 @@ Notes about the template parser:
|
|||||||
|
|
||||||
- assumption: code is large, tables smaller
|
- assumption: code is large, tables smaller
|
||||||
|
|
||||||
|
- smaller tables and code, smaller cache footprint, better performance
|
||||||
|
|
||||||
- how to generate template based stubs:
|
- how to generate template based stubs:
|
||||||
|
|
||||||
make check asn1_compile_FLAGS=--template > log
|
make check asn1_compile_FLAGS=--template > log
|
||||||
|
|
||||||
|
or
|
||||||
|
|
||||||
|
./configure --enable-asn1-templating
|
||||||
|
|
||||||
- pretty much the same as the generate code, except uses tables instead of code
|
- pretty much the same as the generate code, except uses tables instead of code
|
||||||
|
|
||||||
TODO:
|
- much easier to extend! adding new encoding rules is just adding a few
|
||||||
- Make hdb work
|
functions to template.c, one set of length/encode/decode functions per ER,
|
||||||
|
so we could add OER/PER/XDR/GSER/JER with very little work outside that one
|
||||||
|
file and gen_template.c (to generate stub functions) and gen.c (to generate
|
||||||
|
declarations of those stub functions).
|
||||||
|
|
||||||
|
TODO:
|
||||||
- Fuzzing tests
|
- Fuzzing tests
|
||||||
|
|
||||||
- Performance testing
|
- Performance testing
|
||||||
@@ -28,8 +38,30 @@ TODO:
|
|||||||
|
|
||||||
- Fix SIZE constraits
|
- Fix SIZE constraits
|
||||||
|
|
||||||
|
- Proper implementation of `SET { ... }`
|
||||||
|
|
||||||
- Compact types that only contain on entry to not having a header.
|
- Compact types that only contain on entry to not having a header.
|
||||||
|
|
||||||
|
Or maybe not. We can afford larger template footprint if we can get
|
||||||
|
more bang for that. For example, if we add type and member names to
|
||||||
|
the templates, we could have template interpreters that implement JER
|
||||||
|
(JSON Encoding Rules) and/or GSER (Generic String Encoding Rules),
|
||||||
|
and it will cost only the size of the new interpreters plust the
|
||||||
|
extra metadata (type and member names).
|
||||||
|
|
||||||
|
Perhaps we could rely on `dladdr()` to find the names of template
|
||||||
|
data structures and work out the type and member names from that?
|
||||||
|
But then, making more of those static / stripping them would save us
|
||||||
|
some of the cost of adding type and member names to the templates.
|
||||||
|
Using `dladdr()` might be a problem because it's not really portable,
|
||||||
|
and our implementation in lib/roken for WIN32 does not report a
|
||||||
|
symbol name, but there is a way to get that in WIN32
|
||||||
|
(see https://github.com/dlfcn-win32/dlfcn-win32/).
|
||||||
|
|
||||||
|
E.g., if we know the name of a template table as
|
||||||
|
"asn1_TBSCertificate_tag_version_28" then we can work out that it's
|
||||||
|
for the member named `version` in the type named `TBSCertificate`.
|
||||||
|
|
||||||
|
|
||||||
SIZE - Futher down is later generations of the template parser
|
SIZE - Futher down is later generations of the template parser
|
||||||
|
|
||||||
|
Reference in New Issue
Block a user