11 Nov
2016
11 Nov
'16
2:58 p.m.
Hi 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(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)