28 Apr
2020
28 Apr
'20
7 p.m.
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(a)osmocom.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)