Hi Holger, 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 direction: * 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: 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 as lua. 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), ... Yes, understood. Still, those structures could probably simply be copied/wrapped into a msgb? Like the struct that represents a parsed SMS? 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? 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 realistic. 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. Regards, Harald -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)