4 Oct
2009
4 Oct
'09
2:46 p.m.
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