primitives without msgb
laforge at gnumonks.org
Mon Nov 20 13:25:28 UTC 2017
thanks for bringing this up. The original idea of introducing osmo_prim
was for asynchronous primitives being exchanged between individual parts
of a protocol stack. I think the L1/L2 interface in OsmocomBB was one
of the first users. There we also need the async nature, as primitives
are sent over the serial line.
In other parts of the code, like the libosmo-sigtran MTP-USER-SAP or
SCCP-USER-SAP, there are still msgb-wrapped osmo_prim, despite us
currently dispatching them synchronously into the user application code.
The idea was that this could later be evolved into a system where the
related msgb's are sent over a unix domain socket between applications
to isolate the sigtran/sccp stack from the user application.
So my general "road map" for osmo_prim and related SAPs is in that
* turn SAPs into first-class citizens with infrastructure to register
them, VTY introspection, etc.
* have facilities for accessing SAPs from different processes via
unix domain sockets and exchange osmo-prim over sockets
On Mon, Nov 20, 2017 at 08:29:35PM +0800, Holger Freyther wrote:
> The neat thing about this approach is that I don't tie a specific
> scripting solution into the code, the indications are generic enough
> to be useful in multiple contexts, the submit/dispatch is about high
> level operations ("send SMS", "switch device off") that map to other
> programming languages as well. E.g. it is easy to imagine that one
> writes a TCP/IP adapter to send these primitives to another
I very much like this and support it. This is also how I had envisioned
this feature to move ahead: First have some primitives for those
operations, and then use those primitives from a language binding such
> The controversial part is that this code is not using a msgb. Normally
> the primitive header is inside a msgb and then more or less points to
Yes, and the goal of this is to have all information inside the
primitive. We don't pass pointers across a SAP. All information is
self-contained and only identifiers are used to refererence other
state/objects. This means they can be queued, transported over sockets
(at least on the same host where the struct
alignment/padding/endinanness is identical), ...
> But in the scripting layer case the "timer", "new sms", "network
> selection" are already fully parsed objects (or where never parsed
> from a network representation) so are normally not located in a msgb
> in any form.
Yes, understood. Still, those structures could probably simply be
copied/wrapped into a msgb? Like the struct that represents a parsed
> One option is not to bother and deal with the primitive header just
> being embedded in another structure. The concept of
> request/response/indication is bigger than network messages.
correct. However, I think it might actually be good to call things
differently or to find some kind of naming to make it easy for them not
to be confused?
> The other is to create a dummy msgb to obey the interface and follow
> the existing users but I am not sure what we would gain.
We wouldn't gain anything as long as there would still be pointers or
other non-serialized data inside the msgb itself. Wrapping into a msgb
only makes sense if the msgb-wrapped-prim is self-contained.
At that point you gain that you can queue them, work asynchronosly on
them, and that e.g. a script language VM/interpreter/... could run in
a completely different process. I would love to see that, but of course
if it's only possible by crating tons of new struct definitions, copying
the data back and forth, etc. a shortcut like you proposed might be more
But then, given that the number of high-level primitives is expected to
be rather small (perform LU, MO-SMS, MT-SMS, USSD) in theory it should
not be too much data that needs to be converted?
For call control, it occurs to me only now, we could and probably should
actually use the MNCC interface that OsmocomBB already offers. So
existing MNCC primitives (which predate osmo_prim, but which would have
been be a very good fit conceptually) can be created/used by the "script
language process/thread/binding" side to create higher-level functions
that can be used from the script language. So the script would simply
synchonously ask for make_a_mo_voice_call(msisdn) while then the
underlying C code would translate that to MNCC and use the existing
socket for that?
In the end, you are doing the work, and it's your call. I see some
benefits of going the msgb way, but then I don't understand the
implications in detail as you do, working on the given task.
- Harald Welte <laforge at gnumonks.org> http://laforge.gnumonks.org/
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
More information about the baseband-devel