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 <[email protected]> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
