On Thu, Mar 16, 2017 at 11:06:28PM +0100, Harald Welte wrote: 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 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? 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. 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. +1 ~N