DGSM merge: need feedback on open questions

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 osmocom.org
Tue Apr 28 17:00:06 UTC 2020


Hi Neels,

On Tue, Apr 28, 2020 at 05:17:04PM +0200, Neels Hofmeyr wrote:
> we need to wrap up the DGSM work and get it to a state that can be merged to
> master.

Indeed.

> (1) One open point is the GSUP peer identification.  I've added a comment
> explaining it in https://gerrit.osmocom.org/c/osmo-hlr/+/16459/9
> 
> Me personally, I would strip down basically all of that complexity again and go
> with the simplest solution, a nul terminated size limited char string for GSUP
> peer id. The patch became what it is because vague requirements were thrown in
> the mix and I tried to accomodate them, and now it ended up being a rather ugly
> shim around a simple char string, really.

I defer to your judgement.

> (2) Another open question is the freeing behavior in osmo_gsup_req (for proper
> async handling of DGSM, and to ensure proper GSUP responses).  I've added a
> comment explaining that in https://gerrit.osmocom.org/c/osmo-hlr/+/16205/29

No strong opinion either way, slight preference towards the way the patch
currently is.

Let's see if somebody has strong opinions otherwise.
-- 
- Harald Welte <laforge at osmocom.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