Inter-layer state / references / control buffer

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.com
Thu Apr 29 22:19:33 UTC 2010


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




More information about the OpenBSC mailing list