Change in osmo-hlr[master]: 2/2: fixup: add osmo_gsup_peer_id with type enum and union

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.org
Tue Apr 28 14:11:43 UTC 2020


neels 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>


More information about the gerrit-log mailing list