L1SAP and TRX rebase, the last one (TM)

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
Sun Sep 6 13:09:09 UTC 2015


Dear all,

after my futile attempt in September last year to finally merge l1sap
(see the 201409-l1sap branch), I'm making one final attempt.

The following branches have been created + pushed:

* 201509-l1sap:		The core l1sap change that I intend to merge
  This is most of the heavy lifting by introducing L1SAP between the
  sysmobts l1 and the common code.  Hasn't been modified much.

* 201509-trx-rebase:	osmo-bts-trx support that I intend to merge
  This is what I can merge without too much review, as it does not touch
  the common code, except some minor l1sap fixes, and
  * the AMR multirate change, requiring a matching patch on openbsc.git
  * bts_model_abis_close() which should be fine
  * ability to configue multiple TRX from VTY

* 201509-fairwaves-rebase	Stuff I cannot merge in its current form
  * the abis/e1inp multi-trx and reconnect changes require in-depth
    review and testing. Part of it is marked as HACK even by Andreas.
  * a so-called 'fix for use after free' that is actually a patch that
    introduces another copy for every primitive and is only required for
    the loopback mode
  * copying gsm_data_common.[ch] into the repo for debian packaging
    [let's not discuss further work on this before l1sap and trx-rebase
     are merged]

I recommend everyone with a stake in this to review or test the code
in 201509-l1sap and 201509-trx-rebase now.  My schedule is to merge at
some point next week, unless someone raises some serious objections.

What needs to be done after the merge is to unify the
src/common/power_control.c code from Holger originating in master with
src/common/loops.c from Andreas originating from the osmo-trx branch.

There is no doubt that the power control and timing advance loops should
be part of common, as this is required in virtually any BTS hardware.

However, we can safely merge/unify this after the merging of the above
branches.

Regards,
	Harald
-- 
- 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