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/.
Harald Welte laforge at gnumonks.orgHi Neels,
On Thu, Feb 18, 2016 at 12:56:20PM +0100, Neels Hofmeyr wrote:
> Reasons NOT to merge to master in:
>
> asn1c: * aper-prefix
> - ?
If you look at the aper code I took from OpenAirInterface and re-based,
you will see that it does not look 100% complete and would
probably not yet qualify for submitting it to the upstream asn1c
project. The situation is not made better by my hackish way to
implement the type prefixing on top of it by means of an environment
variable.
Specifically, it
* contains commented-out code which might just have been a work-around
of some buggy code, rather than fit for removal in general
* contains TODO comments like "/* TODO: act upon NOTE in #18.7 for
canonical PER */" which hints that it is not properly implementing
parts of the PER specification
* contrary to the rest of asn1c, it does not come with a comprehensive
test suiet for the APER encoding and decoding routines of all types
Any help in cleaning this code up (it could be done for the type
prefixing independent of the APER support) would be much appreciated.
The goal is to get this merged in asn1c, after all.
It might also be worth to contact the OpenAirInterface guys about their
thoughts on moving this code forward. I fear there might be none, as
they are using an ancient version of asn1c to begin with. But they are
a much larger project and might be convinced to put some resources on
doing this properly?
Unless we think something is ready for pushing to upstream asn1c, we
should keep it out of our local master, too.
> libosmo-netif: * sysmocom/sctp
> - ?
I pushed one of the two commits to master.
However, commit 89118114972d587f623305e410d45eb934900e81 basically just
prints some messages to the log file in case there are association state
changes like UP and LOST. This is clearly not the intended behavior.
The application should be notified accordintly in such events,
particularly in 'connection lost' events that can be communicated in the
same way as they can for e.g. TCP sockets.
Only after that is resolved, we can merge it to master.
> libosmo-sccp: * laforge/wip
> - ?
My main problem with this patch set is naming. We are creating an 'SCCP
User SAP' which should look the same no matter what the underlying
transport protocol stacking is. Whether it's SUA/SCTP/IP or
SCCP/M3UA/SCTP/IP or SCCP/MTP3/M2UA/SCTP/IP or SCCP/MTP3/MTP2/E1 or
SCCP/MTP3/MTP2/M2PA/SCTP/IP should not matter to the application.
The sccp_sap.h data structures still follow that rule. However the
sua.h code (creating a SUA client or server, 'struct osmo_sua_user /
struct osmo_sua_link' directly reference SUA.
In terms of the function names I don't care really too much, as
inevitably an application will somehow need to specify the protocol
stacking it would like to use. Either explicitly or implicitly via
system-level configuration of the signalling stack.
However, the application should not have to keep an 'osmo_sua_user'
pointer or an 'osmo_sua_link' pointer in its own data structures. It
should be an opaque osmo_sccp_user / osmo_sccp_link structure, so once
we change from one underlying stacking to another, the data structures
of the application do not have to change.
--
- 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)