Require the same libosmocore version in configure.ac and rpm spec as
already set in debian/control.
Change-Id: I701f1aacca22a697f35aba0041a71945c5aea107
Create m4/.gitkeep to eliminate the following warning:
aclocal: warning: couldn't open directory 'm4': No such file or directory
Add 'AC_CONFIG_MACRO_DIRS([m4])' to configure.ac to as suggested:
libtoolize: Consider adding 'AC_CONFIG_MACRO_DIRS([m4])' to configure.ac
Change-Id: Id9d605490c4b403b99ed54745838cc9f242030c3
During code review, it was indicated that some TLV protocols that we
will likely deal with in the near future also employ an I, and instance
value of a tag. Add TLIV support.
A usage example for a manually implemented TLIV structure is found in
tests/libosmo-gtlv/gtlv_test.c.
A usage example for a generated TLIV protocol is found in
tests/libosmo-gtlv/test_tliv/.
Related: SYS#5599
Change-Id: I0a076e54dfba6038cc779cb7c8f3967d212226aa
Defining a protocol of message types with lists of IEs bears a lot of
repetitive, copy-paste-error-prone writing out of data structures.
Add a third layer to libosmo-gtlv, which allows helpful code generation.
By non-repetitive data structures that briefly describe the protocol's
messages and IEs, generate possibly repetitive IE list arrays and
decoded-struct definitions automatically, avoiding grunt work errors.
I tried C macros for this at first, but it became too convoluted.
Generating C code that can be read and grepped makes things easier.
A usage example is found in tests/libosmo-gtlv/test_gtlv_gen/.
Related: SYS#5599
Change-Id: Ifb3ea54d2797ce060b95834aa117725ec2d6c4cf
An all new TLV parser supporting:
- Any size of T and L (determined by callback function),
- "Grouped IEs", so that an IE payload is a nested IE structure,
- optional/mandatory/multi-occurence IEs,
- decoding unordered tags (or enforcing strict order).
Will be used for PFCP message decoding and encoding, a T16L16V protocol
which requires above features.
Upcoming patches add
- translating PDUs to plain C structs and vice versa
- TLV generator to reduce repetition a in protocol definition
- TLIV capability
Previously, the way we deal with TLVs causes a lot of code
re-implementation: the TL decoding is taken care of by the API, but for
encoding, we essentially re-implement each protocol and each encoded
message in the individual programs. This API is an improvement in that
we only once implement the TL coding (or just use osmo_t8l8v_cfg /
osmo_t16l16v_cfg), get symmetric de- and encoding of the TL, and only
need to deal with the value part of each IE.
The common pattern of
- store TL preliminarily,
- write V data and
- update L after V is complete
is conveniently done by osmo_gtlv_put_update_tl().
Related: SYS#5599
Change-Id: Ib0fd00d9f288ffe13b7e67701f3e47073587404a
Oliver Smith
Vadim Yanitskiy
Neels Hofmeyr
Neels Hofmeyr