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/.
Sylvain Munaut 246tnt at gmail.comHi 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