On 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