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/gerrit-log@lists.osmocom.org/.
neels gerrit-no-reply at lists.osmocom.orgneels has posted comments on this change. ( https://gerrit.osmocom.org/c/osmo-hlr/+/16459 ) Change subject: 2/2: fixup: add osmo_gsup_peer_id with type enum and union ...................................................................... Patch Set 9: Let me recap the problem space around this patch: - the IPA multiplex protocol has an arbitrary data+length field for peer identification. - in osmo-hlr DB, the peer identification is defined as VARCHAR(32), but SQLite does not enforce the length of 32 (it becomes a TEXT field under the hood). - I think the idea was a decimal number to identify VLR and HLR - in hlr_subscriber, we use a char {vlr,sgsn}_number[32], i.e. hard limited to 31 chars plus nul, since most code expects nul termination. - in osmo-hlr cfg and code, we use an arbitrary C string (nul terminated) - we'd like to be open to a DIAMETER future with an arbitrary blob as identification? - ...with a global title as identification? The struct osmo_gsup_peer_id came about because many code paths passed a data+length pointer around as arguments, with unclear data ownership issues. I needed to clarify that with a simple self-contained struct that is certain to have no hidden dynamic allocation going on, and which will survive async event handling. The current state of this patch is attempting to be a universal data type open to all of the above interpretations, which I am unsure about. I don't like very much how convoluted this has become, especially since being this universal is not supported by many code paths. If we kept it simple and stick to the current actual usage, we would simply enforce all GSUP peer identification to be a nul terminated string of max 31 characters plus a nul. Expanding from that: - Having more length would require adjusting hlr_subscriber's max length. - Having an arbitrary blob would require: - changing the DB schema - inventing some way to configure BLOBs in the osmo-hlr.cfg - I am not familiar with how we would tie in a DIAMETER identification. If there are any opinions or aspects I missed, I'd be glad to hear them. -- To view, visit https://gerrit.osmocom.org/c/osmo-hlr/+/16459 To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings Gerrit-Project: osmo-hlr Gerrit-Branch: master Gerrit-Change-Id: Ide9dcdca283ab989240cfc6e53e9211862a199c5 Gerrit-Change-Number: 16459 Gerrit-PatchSet: 9 Gerrit-Owner: neels <nhofmeyr at sysmocom.de> Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: fixeria <axilirator at gmail.com> Gerrit-Reviewer: laforge <laforge at osmocom.org> Gerrit-Reviewer: neels <nhofmeyr at sysmocom.de> Gerrit-Reviewer: osmith <osmith at sysmocom.de> Gerrit-Reviewer: pespin <pespin at sysmocom.de> Gerrit-Comment-Date: Tue, 28 Apr 2020 14:11:43 +0000 Gerrit-HasComments: No Gerrit-Has-Labels: No Gerrit-MessageType: comment -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.osmocom.org/pipermail/gerrit-log/attachments/20200428/357fbd0d/attachment.htm>