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