plan for openbsc.git split and code review

[Neels Hofmeyr]

On Tue, Jul 11, 2017 at 09:09:37PM +0200, Harald Welte wrote:
> > The libmgcp has so far been internal to openbsc.git. I intend to make it an
> > installed library from osmo-mgw.git (similar to libosmo-ranap from
> > osmo-iuh.git), as libosmo-mgcp.  libmgcp is used by MSC and BSC to communicate
> > with osmo-mgw (osmo-bsc_mgcp).  Also by osmo-bsc_nat, which I had actually not
> > been aware of until now.
> 
> I think we have to be careful to review its API in detail before making
> it a public, system-installed library where we have to deal with API or
> ABI breakage of anything we modify later on.
> 
> One idea that Holger formerly pursued with libsccp.a was to only have
> static libraries - we might revisit that idea if we cannot go through
> related API review.

I'm not really aware how a dynamically linked libosmo-mgcp has more problems
than a static one. About the API I notice that there is a header called
mgcp_internal.h, with a comment "Private data" at the top, suggesting that it
would be used only within mgcp*.c; but osmo-bsc_nat wants to use that header
file and its functions, so I added this header to the install. This just to say
that indeed there may be some review, renaming, rearranging at hand.

My idea is to first get it to work with as little modifications as possible
(besides renaming directories / larger scopes), and refine the structure later.
The review process may become rather important...


> > libiu, shared between MSC and SGSN, has already moved to osmo-iuh.

Correction: I thought that we had already merged it, but in fact it's still on
a private branch of mine.
Now https://gerrit.osmocom.org/3187

> I presume it is then called libosmo-iu ?

What our libiu does is actually dock fairly tightly to libosmo-ranap, providing
the code that each of the Iu interfaces use commonly to act as a RANAP
endpoint. Hence I decided to include it in libosmo-ranap as iu_client_*.

One reason to indeed want to separate it again could be that it uses
libosmo-sigtran, accepting an sccp instance like this:

int ranap_iu_init(void *ctx, int log_subsystem, const char *sccp_user_name, struct osmo_sccp_instance *sccp,
                  ranap_iu_recv_cb_t iu_recv_cb, ranap_iu_event_cb_t iu_event_cb)

Including in libosmo-ranap was the simplest way to go. The osmo-iuh build
depends on libosmo-sigtran anyway because of OsmoHNBGW, and all users of
libosmo-ranap also naturally link libosmo-sigtran already.


> > I believe it is appropriate to move the gsup_client along to
> > libosmocore, even though the notion so far has been to keep it out of there.
> 
> The problem is again API/ABI stability.  It restricts the way we can use
> code, and I would prefer to avoid constraining ourselves...
>
> > Otherwise we either duplicate the gsup_client or need another separate
> > libosmo-gsupclient.
> 
> I don't like the latter part.

Are you implying that we should indeed duplicate?

The same rationale could actually apply to above iu client.

I don't know; Yes, it's not really that much code to duplicate, but keeping
separate copies of entire APIs feels undesirable. Is modifying the API/ABI
really such a big problem? "Simply" keep older function signatures, possibly
deprecate some, possibly even make a breaking change and depend on new library
versions occasionally ... isn't that expected daily business?

~N
-------------- 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/20170712/b20223b4/attachment.bin>