Hi Harald,

> instead of building more hacks on existing hacks, we should probably
> consider to use our TLV parser instead

[... patch snipped ...]

> all that we need is a second 'struct tlv_parsed' on the stack, as well as
> a 'static const struct tlv_definition' for the nested attributes such as
> SW_DESCR and FILE_ID, FILE_VERSION (or any others, if they exist).

Mmmm, I don't really see how to do that without another hack ...

* You can view it either as flat (liek the wireshard dissector does) like this :

SW_CONFIG
FILE_ID len_16 data
FILE_VERSION len_16 data
SW_CONFIG
FILE_ID len_16 data
FILE_VERSION len_16 data

But then the problem is that the tag will override each other in the tlv_parser, you can't really 'choose' which config you get.

* Or you can view the FILE_ID & FILE_VERSION as 'nested into' SW_CONFIG:

SW_CONFIG
FILE_ID len_16 data
FILE_VERSION len_16 data
SW_CONFIG
FILE_ID len_16 data
FILE_VERSION len_16 data

But that's not better, because even if I start tlv_parsing a sw_config+1, SW_CONFIG tag doesn't have a 'length' it's just defined as having two child, so I can't really tell the tlv_parser to stop and it will continue past the first FILE_VERSION and into the second SW_CONFIG tag.

Or am I missing something obvious here ?

Sylvain