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/libosmocore/+/18506 ) Change subject: add gsm23236: MSC pooling: TMSI and NRI utility functions ...................................................................... Patch Set 4: > one *could* (not saying you must if you don't like it) create a 'osmo_nri_range_list' or 'osmo_nri_ranges' struct which stores the master llist_head, the nri_bitlen and which also serves as talloc context for any osmo_nri_range allocations. This way the function signatures (and hence usage) would be simplified without having to manually specify ctx and/or nri_bitlen. If the osmo_nri_range had a back-pointer to the ramnge_list/ranges "parent", then even functions only receiving a single osmo_nri_range as argument can get to the nri_Bitlen. Putting the nri_bitlen in a 'osmo_nri_ranges' struct is not so good, because e.g. in osmo-bsc there will be one global nri_bitlen for all ranges, and duplicating that global value across several ranges is inviting trouble. (It must be one single value for the entire MSC pool, otherwise the logic doesn't work out.) Using a 'struct osmo_nri_ranges' as talloc ctx: I've used that pattern before, thinking of struct neighbor_ident_list. There I also wanted to keep as much of the structs opaque, which ended up more trouble than gain. Now I swerve the other way, I kind of like the simplicity of just using a non-dynamic llist_head. Thinking about it, it makes for cleaner API to make the head a dynamic struct; but that struct will only contain an llist_head and that's it. We can only save the ctx argument. OTOH if we want future additions to a struct osmo_nri_ranges, then an llist_head is less future proof. So seems worth it to go for a dynamic struct osmo_nri_ranges with only an llist_head member... I am also considering to combine a list of NULL-NRI in a struct osmo_nri_ranges, but that makes NULL-NRI handling less flexible. (e.g. a NULL-NRI is kept per PLMN and not per MSC, but we have a separate NULL-NRI list for each MSC of the same PLMN, doesn't match well) -- To view, visit https://gerrit.osmocom.org/c/libosmocore/+/18506 To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings Gerrit-Project: libosmocore Gerrit-Branch: master Gerrit-Change-Id: Icb57a2dd9323c7ea11b34003eccc7e68a0247bf5 Gerrit-Change-Number: 18506 Gerrit-PatchSet: 4 Gerrit-Owner: neels <nhofmeyr at sysmocom.de> Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: laforge <laforge at osmocom.org> Gerrit-Reviewer: neels <nhofmeyr at sysmocom.de> Gerrit-CC: Vadim Yanitskiy <vyanitskiy at sysmocom.de> Gerrit-CC: pespin <pespin at sysmocom.de> Gerrit-Comment-Date: Wed, 03 Jun 2020 14:32:30 +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/20200603/66b7a176/attachment.htm>