ns2 thoughts

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/osmocom-net-gprs@lists.osmocom.org/.

Harald Welte laforge at gnumonks.org
Mon Sep 21 17:52:19 UTC 2020


On Mon, Sep 21, 2020 at 05:50:17PM +0200, Alexander 'lynxis' Couzens wrote:

> > == consider using an osmo_ prefix to all symbols / types
> > 
> > The fact that the old code doesn't have that is a tribute to its age,
> > and not something we need to keep.  The current code has quite a bit
> > of 'gprs_ns2' prefixing for types, but not for the symbols/functions.
> >  At least that inconsistency should be resolved, so all have the same
> > prefix, even if it is without osmo.
> 
> The concept was prefix gprs_ns2 for public symbols and ns2 for
> internal since some functions are used across files within libosmocore.

oh, great.  I somehow missed that.

> The osmo_ prefix sounds a lot cleaner.

I guess we can keep it as-is.  If you want, go for osmo_ns2 as public
prefix, but I'm not sure it's worth the effort at this point.

> Not sure if the effort for the msgb->dst is worth because we're only
> using it internal. I don't have an opinion on this.

yes, let's just keep it as-is.

> Except if we want to use the pointer for the resource distribution
> function [48.016 4.4a].

interesting.  I'm not deep enough into the topic to have an opinion
about it right now, sorry.

> > There are functions like gprs_ns2_find_vc_by_sockaddr() where the
> > result is not returned, but rather a **pointer output argument is
> 
> In general I like the difference between result and return code.
> ACK on gprs_ns2_find_vc_by_sockaddr() where there isn't much in the
> result code.

agreed.  return the result whenever there is nothing to return.

Thanks.

-- 
- 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)



More information about the osmocom-net-gprs mailing list