coverity scan for vlr_2G and vlr_3G

historical

On Thu, Mar 16, 2017 at 11:06:28PM +0100, Harald Welte wrote:
> The [post-VLR] repository currently contains the following main programs
> (excluding various utilities like abisip-find, isdnsync, measurement
> stuff, ... :
> 
> * osmo-bsc
> * osmo-bsc_nat
> * osmo-msc (NITB without HLR and BSC)

To clarify for anyone else reading along: the VLR, i.e. libvlr, sits in the
OsmoNITB, closely tied to libmsc, on the vlr_2G and vlr_3G branches. See also
the block diagrams towards the end of https://osmocom.org/news/67

> So in terms of clean-up, one of the questions is: what exactly do the
> circuit switched programs share with the packet-switched ones?

The answer to this *should* be: anything found in libcommon. For things shared
among the circuit-switched parts, we have libcommon-cs, so the rest should be
relevant for cs + ps ... However, that's not accurate.

Taking a look at libcommon:

Used everywhere but makes sense to separate instead:
  bsc_version.c  -- just the copyright string
  common_vty.c   -- vty_go_parent() combined for various VTY trees
  debug.c        -- logging categories and filters, combined

Only related to gprs because above debug.c combines unrelated scopes:
  gsm_subscriber_base.c -- debug.c filter_fn uses msc/bsc subscr_get()/subscr_put()

Completely unrelated to gprs:
  gsm_data.c     -- except tall_bsc_ctx, gprs should have its own.
  gsm_data_shared.c
  talloc_ctx.c
  socket.c       -- actually only used by osmo-bsc_nat and ipaccess-proxy,
                    should probably use libosmocore socket code instead?

Used across gprs and cs:
  gsup_client.c       -- not yet, but used by CS on vlr_2G branch
  gsup_test_client.c
  oap_client.c

These are proven / illustrated by a playful branch that moves things to
libcommon-cs: https://git.osmocom.org/openbsc/log/?h=neels/libcommon-cs

In fact it looks like rather than splitting off libcommon-cs, we should have
created a libosmo-gsupclient and left libcommon to be used by cs programs only,
separating the minor generic bits to gprs/.

Then there's also libiu, which is shared across OsmoSGSN and OsmoMSC on the 3G
branch to provide IuPS and IuCS, respectively.

In summary: only gsup_client and libiu are shared across cs and ps, both of
which are also just needed by libmsc/libvlr and OsmoSGSN. (not by osmo-bsc*,
not by gb_proxy nor by any utils.)

If we wanted to completely separate cs from ps, we could technically move
gsup_client to libosmocore and libiu to osmo-iuh. That would allow having
separate osmo-bsc+msc and osmo-sgsn repositories. Actually, our plans for
separating MSC and BSC also calls for separating gsm_subscriber_connection and
gsm_network, and at that point it would also make sense to have separate
osmo-bsc and osmo-msc repositories. The names would then come naturally.  We
could install libbsc from osmo-bsc and link it in from osmo-msc to build
OsmoNITB while we still need to; and when the A-interface comes along stop
linking libbsc from osmo-msc.

If we keep bsc, msc and gprs combined, we need to come up with a logical name.
Maybe the fact that we still haven't found one is an indicator that we should
rather separate openbsc.git up by the familiar names as above?

> In redmine we have the 'cellular infrastructure' project as a parent to
> all the 2G/3G related projects.  Maybe we should call it
> 'osmo-cell-infra', 'osmo-2g3g' or even more generic 'osmo-cellular'?
> that's actually again a bit too generic, as the BTS and PCU are prime
> example of other cellular infrastructure projects that are not part of
> that repo.  Also, there's the HLR which lives in a separate repo -
> simply because it shares no code with the other projects.  Still, it
> might actually be worth to consider merging it into the same repo as the
> MSC.

With steve, the name Osmocom-CN has kind of stuck, for osmocom core network.
But again the HLR is separate and it's not really accurate. Osmocom-CN would
make sense if we have a joint BSC, MSC, SGSN and HLR repository.

> Maybe a non-descriptive name should be used?  Or, in the great tradition
> of the telecom world, yet another acronym?

Nondescriptive... osmo-kitchensink? :P

Weird that they should have so many acronyms like SIGTRAN, NAS, GERAN/UTRAN,
and none of them match our intended grouping :)

But what *is* our intended grouping?  I (naively?) tend to like complete
separation into separate BSC, separate MSC, separate SGSN, because it matches
the separation that the code is moving towards, and our redmine project tree.

> In general, when we do the "fork" to the new repo, I would like to use
> the opportunity to get rid of the extra 'openbsc' sub directory

+1

~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/20170318/a5e9927d/attachment.bin>