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/.
Neels Hofmeyr nhofmeyr at sysmocom.deOn 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. My latest summary on this is: - keith had no time to look at this, says to go ahead and deal with the merged situation later. - pespin would prefer an opaque data structure for peer id, for ABI compat reasons. - I'm reluctant to add opaque data because that requires dynamic allocation. Concerning future ABI compatibility, I agree that it would be a nice thing but is not a hard requirement. IMHO it isn't worth adding dynamic allocation (and rewriting many patches on this branch) for it. - laforge indicates slight preference of the patch staying as it is now. - I would actually prefer a plain char string (the current real world usage). My gut feel is that the peer id will remain API bloat forever, but it gives the benefit of the doubt to being able to expand the API compatibly in the future. Seems like everyone is pointing in a slightly different direction. But I think most of our concerns are rather scratching the surface rather than being substantial deep review on the core implementations of D-GSM. In the last patch set, I only renamed osmo_gsup_peer_id to osmo_cni_peer_id, added some API doc and tweaked some commit log messages, added a const. So, essentially, these patches are still the same that they have been for months I've probed the patches for desirable changes for a while and seem to hit reasons to not change anything in every direction. So we either find agreement on how to change these patches, or we merge them as they are. I think there is agreement that we don't want to keep this on a branch for much longer, so I'd ask reviewers to converge on a verdict, ideally one that says CR+2... On the level of maturity: osmith and I have tested the D-GSM setup a lot, and the substantial code changes in osmo-hlr (new LU FSM and osmo_gsup_req and peer id) have already been running at 36c3 in Leipzig without issues. ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20200430/bf2bc57f/attachment.bin>