Dear all,
We recently discussed with Harald, that there is a lot of code related to GSM L1 should be migrated from OsmoBTS to libosmogsm. The reason is that it would be better to have one shared implementation of the convolutional codes, mapping, interleaving, etc., because then in near future it can be used not only from OsmoBTS, but also from OsmocomBB and even from foreign projects, such as GR-GSM.
I just started to work on this direction, and found that there is already some code, related to the conventional codes, in libosmogsm. But unlike OsmoBTS, where all the tables can be found within the single file named 'gsm0503_conv.c', these tables appears in separate files during building process. So, I have several questions:
1) Which approach is better to use? To store everything in a single file or to use auto generation (utils/conv_gen.py)? 2) What about the copyright? I have not seen any license/author info at the top pf these files. Who is the author?
Also, there is the 'gsm0503_coding.c' file, which uses the following external dependences:
* The DL1C logging category, which isn't defined in libosmocore; * The 'osmo-bts/gsm_data.h', which includes 'openbsc/gsm_data_shared.h' as well.
So, there is regarding questions:
3) Which logging category it would be better to use after migration? 4) What to do with the 'osmo-bts/gsm_data.h'? 5) I don't think, that it's a good way to require something from the OpenBSC sources during OsmoBTS build... How can we change it?
With best regards, Vadim Yanitskiy.
Hi.
I think I can answer some of the questions. See comments below.
On 08/04/2016 01:50 PM, Vadim Yanitskiy wrote:
- 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.
- What about the copyright? I have not seen any license/author info at
the top pf these files. Who is the author?
Could you specify which files exactly are you referring to? Also you can use 'git blame' to clarify authorship.
Also, there is the 'gsm0503_coding.c' file, which uses the following external dependences:
- 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.
Hi Max and others,
On Thu, Aug 04, 2016 at 02:54:17PM +0200, Max wrote:
- 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)
On Thu, Aug 04, 2016 at 05:50:39PM +0600, Vadim Yanitskiy wrote:
- The 'osmo-bts/gsm_data.h', which includes 'openbsc/gsm_data_shared.h' as well.
So, there is regarding questions:
- Which logging category it would be better to use after migration?
- What to do with the 'osmo-bts/gsm_data.h'?
- I don't think, that it's a good way to require something from the
OpenBSC sources during OsmoBTS build... How can we change it?
I've also faced the problem twice recently that I effectively can't log from gsm_data_shared.c, since the logging constants (e.g. DRSL) are defined separately for openbsc and osmo-bts (can't include both headers...).
The first time I solved it by returning an error code and code-dup'ing the error logging in osmo-bts and openbsc (see lchan_lookup() in openbsc/src/libbsc/abis_rsl.c and osmo-bts/src/common/rsl.c).
The other time I placed a compile time #warning where I'd have preferred to post an error log (not committed yet).
The one advantage of gsm_data_shared.c is that I feel that I can modify that API without breaking any libosmocore ABI. We can pretty freely drop stuff in there and re-use across openbsc and osmo-bts that isn't used anywhere else.
But I find these solutions rather unsatisfactory / ugly and would +1 for solving the gsm_data_shared.c evil-twin situation. If some of the stuff isn't worthy of moving to libosmocore, we'd need another tiny osmo-lib?
~Neels
Hello everyone!
I am happy to report, that the GSM 05.03 code migration from OsmoBTS is finished now. For details, please see:
https://gerrit.osmocom.org/#/c/816/
With best regards, Vadim Yanitskiy.
2016-08-09 0:06 GMT+07:00 Neels Hofmeyr nhofmeyr@sysmocom.de:
On Thu, Aug 04, 2016 at 05:50:39PM +0600, Vadim Yanitskiy wrote:
- The 'osmo-bts/gsm_data.h', which includes 'openbsc/gsm_data_shared.h' as well.
So, there is regarding questions:
- Which logging category it would be better to use after migration?
- What to do with the 'osmo-bts/gsm_data.h'?
- I don't think, that it's a good way to require something from the
OpenBSC sources during OsmoBTS build... How can we change it?
I've also faced the problem twice recently that I effectively can't log from gsm_data_shared.c, since the logging constants (e.g. DRSL) are defined separately for openbsc and osmo-bts (can't include both headers...).
The first time I solved it by returning an error code and code-dup'ing the error logging in osmo-bts and openbsc (see lchan_lookup() in openbsc/src/libbsc/abis_rsl.c and osmo-bts/src/common/rsl.c).
The other time I placed a compile time #warning where I'd have preferred to post an error log (not committed yet).
The one advantage of gsm_data_shared.c is that I feel that I can modify that API without breaking any libosmocore ABI. We can pretty freely drop stuff in there and re-use across openbsc and osmo-bts that isn't used anywhere else.
But I find these solutions rather unsatisfactory / ugly and would +1 for solving the gsm_data_shared.c evil-twin situation. If some of the stuff isn't worthy of moving to libosmocore, we'd need another tiny osmo-lib?
~Neels
--
- Neels Hofmeyr nhofmeyr@sysmocom.de http://www.sysmocom.de/
=======================================================================
- sysmocom - systems for mobile communications GmbH
- Alt-Moabit 93
- 10559 Berlin, Germany
- Sitz / Registered office: Berlin, HRB 134158 B
- Geschäftsführer / Managing Directors: Harald Welte
-
Harald Welte -
Max -
Neels Hofmeyr -
Vadim Yanitskiy