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/.
Neels Hofmeyr nhofmeyr at sysmocom.deOn 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>