Hi Harald,
In our case, we would actually want to have the
associated data to persist
even while the msgb passes from one layer into another. This would mean
that there is a more-or-less static structure containing all the various
identifiers, which is then typecasted to the control buffer.
While this might not be ideal, it definitely keeps the details hidden
away from libosmocore, which is good.
FWIW, I think it's a good idea. When I had a first look at the gprs
branch a few months ago, all those new fields required in msgb
definitely were something I wasn't thrilled to see.
As I see it, it might not be perfect but :
- It does the job
- It's a whole lot better than the current situation
- It's simple to understand
One question that pops to mind is :
- Would allocation / freeing of those be handled by msgb routines ? I
would think so since that'd avoid error and I don't see any loss of
'genericity' in doing that, but just asking.
Also, would you include the various header pointer in this cb struct
or splitted ?
Personaly, I'd still see them splitted but more something like
"uint8_t *h[8];" and let the application define its own
macros msgb_ns_hdr(), msgb_rsl_hdr(), msgb_gmm_hdr() that map to the
unique 'h' pointer rather than things like
union {
unsigned char *smsh;
unsigned char *llch;
unsigned char *l4h;
};
This way the msgb wouldn't show even any 'gsm' aspect and would just
be a generic message buffer ...
Cheers,
Sylvain