This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.
246tnt at gmail.com 246tnt at gmail.comHi 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20091004/d5dada48/attachment.htm>