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@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.