7 patches

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

Holger Hans Peter Freyther holger at freyther.de
Fri Jul 26 10:12:53 UTC 2013


On Mon, Jul 15, 2013 at 12:07:58PM +0200, Andreas Eversberg wrote:
> hi,
> 
> these 7 patches have been tested with sysmobts and osmo-bts (trx
> interface). it works with calls and gprs. before applying any of these
> patches, i suggest to double check it with a different test setup.

Hi,

I don't have much time to do QA in spare my time. So this is very
brief:

* Doing the stress-testing I described on 4th and 6th of May. A
  compiled sysmobts binary with your changes is crashing on a
  talloc_free. zecke/hacks/stress-testing, executing allocate-all-channels
  will crash the code. I am confident that this is not due a binary
  incompatible change to the header files (we need to bump the
  so version of libosmocore in the next cycle)

* You are undoing all the lchan->s changes we did based on my review
  we did from 12th of March to 15th of March. To be honest I find
  this quite offensive.

* The extra msgb_alloc/memcpy to go from primitive to native is
  wasteful. One should re-write the header around the payload.

* The change to introduce the primitives is too big. Otherwise the
  above two issues could have been spotted with review. My proposal
  is to introduce primitives inside the sysmoBTS code piece by
  piece in one primitive per patch.

    E.g. introduce a 'native' primitive and the l1sapup, then start
    converting that to other primitives until there are no native
    primitives left. Avoid creating a thousand lines switch/case
    statement. Modern compilers will nicely inline small static
    methods.

  The benefit is that each change can be easily reviewed and stress
  tested (e.g. compare it with the changeset I did for the sapi queuing),
  and one avoids such things like undoing lchan->s changes that are
  burried somewhere in the patch.

cheers
	holger




More information about the OpenBSC mailing list