OsmoBTS -> libosmogsm code migration

historical

Hi all!

I would like to inform, that this task is almost finished! Just tested
my changes, and build was successful without any warnings. But I still
have a couple of unresolved issues:

I have some problems with understanding how to add a new item into the
convolutional codes generator (utils/conv_gen.py), so temporary I just
used a single file from OsmoBTS (gsm0503_conv.c) to check, if all the
rest forks fine. If someone (Max?) can help me to move missed tables
(mostly EGPRS specific, see 73cb583e5147a267a370c576e8ac77507de6d0d7),
I will be grateful, and the task will be completely finished soon.

Also, there are several external dependences from libosmocodec, such as:

 - gsm620_unvoiced_bitorder
 - gsm620_voiced_bitorder
 - gsm660_bitorder
 - gsm610_bitorder

They are some uint16_t arrays, related to GSM HR, FR and EFR. It's sadly,
that they cannot be included using exactly corresponding header files.
I think there are three possible ways to solve this problem:

 1. Link gsm620.c, gsm660.c and gsm610.c to libosmogsm sources.
     (I am not sure, that it is a good way...)
 2. Copy required arrays to libosmogsm (also unlikely).
 3. Add libosmocodec.la as dependence (I suggest exactly this solution):
     - libgsmint_la_LIBADD = ../libosmocore.la
     + libgsmint_la_LIBADD = ../libosmocore.la ../codec/libosmocodec.la

All other problems was solved.

With best regards,
Vadim Yanitskiy.

2016-08-04 19:51 GMT+06:00 Vadim Yanitskiy <axilirator at gmail.com>:

> Hi Max,
>
> Thanks for your reply!
>
> > 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.
>
> Ok, I will keep your opinion in my mind.
>
> > Could you specify which files exactly are you referring to? Also you can
> > use 'git blame' to clarify authorship.
>
> No problem, they are:
>
>  - gsm0503_conv.c
>  - gsm0503_interleaving.c
>  - gsm0503_mapping.c
>  - gsm0503_parity.c
>  - gsm0503_tables.c
>
> Almost all the gsm0503_*, excluding the 'gsm0503_coding.*'.
> Thank you for this hint, this command is very usable! :)
>
> > 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 am agree with you. It's time to use return codes.
>
> Have a nice day!
>
>
> With best regards,
> Vadim Yanitskiy.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20160806/cd1e2f61/attachment.htm>