OsmoBTS -> libosmogsm code migration

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.org
Mon Aug 8 08:46:23 UTC 2016


Hi Max and others,

On Thu, Aug 04, 2016 at 02:54:17PM +0200, Max wrote:

> > 1) Which approach is better to use? To store everything in a single file
> > or to use auto generation (utils/conv_gen.py)?
> 
> I think extending utils/conv_gen.py is the way to go because it will
> allow us to have concise description of the convolutional codes in one
> place and as close to the description in standards as possible.

agreed.

> >  * The DL1C logging category, which isn't defined in libosmocore;
> 
> I don't think library functions should do any sort of logging by itself
> (unless it's a logging functions of course :)
> Instead they should return clearly distinguishable values and let caller
> do the logging as they see fit.

I tend to agree in the case of the convolutional coding - but we do have
plenty of library code that makes use of logging.  See the LAPD / LAPDm
code, for example.

There's two options for this, either:

a) introduce a DL___ logging category which "lives" entirely inside the
   library (like LAPD), or
b) have the application pass in the log sub-system value to be used by
   the library code (used e.g. in FSM code)

-- 
- 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 OpenBSC mailing list