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/.
Neels Hofmeyr nhofmeyr at sysmocom.deOn Sat, Apr 02, 2016 at 01:47:48AM +0200, Harald Welte wrote: > You shouldn't have to care about the detailed usage of the cb[] as every > program / library / protocol stack should have it's own wrappers and > inline functions or macros to obtain the respective values ok ... I see. > The l2h/l3h should proably be used less and more with a wrapper macro, > too. Like 'msgb_rslh()' to get the rsl header, or the like. msgb->l3h > should really only be used in cases where there is a clear definiton > what the layer3 protocol is. In GSM, it is RR/MM/CC. The problem is > that depending on the interface (Abis/A/Iuh/Iub/IuCS), below can be > multiple sub-layes of 'layer 2'. GSM is by far the most complex thing I've worked on in terms of layerings and specifications. It often seems so simple to just tell the other side what should happen, but to get it across takes layers of hard work ;) > Allocating blocks of memory in equal size is often/typically more > efficient and leads to less memory fragmentation than allocating odd ok, makes sense. > Is it really that much more difficult to write "oph->msg->l2h" than to [...] > Why would you have to worry or care how things are ordered in memory? I > really don't understand this part, sorry ;) Why would you care? I think my problems start when I "briefly" want to understand everything about a given code path, but am tumbling down a rabbit hole of indirections and generic names used all over the place. Try to grep for 'cb' and you'd get huge amount of hits completely unrelated to a given 'cb' you might want to grok. If things are named explicitly, it's quite easy to grep for source and sinks of values put in it. It's not harder to write things down, It's just often hard to find out on my own what to write down ;) My progress is often slow these days because I try to understand things, and that takes more work than I expect... Well, but I'm getting there. > Your typical primitive-consuming function gets a > 'struct osmo_prim_hdr *' as input, and from there you > > a) know how to get to the msgb from that (oph->msgb) > > b) know how to get the SAP-specific larger primitive structure from it > > c) know how to get to a particular layer header at any level of your > protocol stack inside the msgb (msgb->l2h/l3h/...) With a firm map like this in your head, it sounds quite straightforward, yes. I've come from the other side: I saw a bare msgb struct and didn't know how to navigate it, first need to find the infrastructure around it. > Things that I think would improve the situation: > > * include a 'magic value' in the msgb->cb[] that defines which structure > is currently type-casted to it. This way we could have assert-style > macros at various places in the code, making sure that nobody is > trying to dereference it to the wrong structure > * reduce the amount of direct lXh accesses, particularly for != l3h. In > fact, they predate the cb, and if we had a cb from the beginning, they > might not even have needed to exist. > * document the usage of msgb (particularly lXh and cb usage) for each > prtoocol/interface/stack/sap. Sounds pretty good: a new reader should be guided to the higher level view and specific usage within a given protocol stack. Assertions for 'magic values' in the code could highlight that and guide to the documentation. ~Neels -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20160403/15f71e82/attachment.bin>