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 Fri, Nov 11, 2016 at 12:50:01PM +0100, Neels Hofmeyr wrote:
> struct gsm_network
> (note, if there is a common part, that could still be named 'gsm_network')
>
> --> bsc_network / msc_network
> looks familiar but the meaning of the name is lost
>
> --> gsm_bsc / gsm_msc
>
> --> osmo_bsc / osmo_msc
> To me these would be the best and the names are still available, but there
> are header files named like this and the osmo-bsc binary also has a very
> similar name. I think I would go for these anyway.
> +1
>
> --> osmo_gsm_bsc / osmo_gsm_msc
> As alternative, but the gsm is a bit out of place (particularly in the
> light of a UMTS MSC).
In general we shouldn't call structures how we are (or might be) calling
functional elements. So if it's a msc or bsc instance or context,
postfix it by _inst, _instance, _ctx or _context.
Also, the osmo_ naming prefix makex mostly sense in the conext of
library code to avoid namespace pollution. I think I actually like it
if application code structures and symbols do not have osmo_ prefixes.
> struct gsm_subscriber_connection
>
> --> bsc_subscriber_connection / msc_subscriber_connection
> but we could use the opportunity to shorten the name
>
> --> bsc_subscr_conn / msc_subscr_conn
> I like these best; but add osmo?
> +1
fine with me.
--
- 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)