Attention is currently required from: laforge, pespin. neels has posted comments on this change. ( https://gerrit.osmocom.org/c/osmo-hnbgw/+/33173 )
Change subject: cnpool: add context_map_cnlink_lost() handling ...................................................................... Patch Set 5: (1 comment) File include/osmocom/hnbgw/context_map.h: https://gerrit.osmocom.org/c/osmo-hnbgw/+/33173/comment/ef9087e2_482997fc PS3, Line 70: MAP_SCCP_EV_CN_LINK_LOST, > The main problem here is that "LINK_LOST" is too generic and difficult to > understand from reader poi […] There is a reason why this name is vague, on purpose: It is not this FSM's concern why this SCCP conn should go away and discard ungracefully. It might be an SCTP ABORT or a RANAP RESET or whatever. Incidentally it is so far exactly a RANAP RESET on connectionless transfer, but what may be the root reason is out of scope of this FSM. The caller has concrete reasons with accurate names, this FSM here only needs to carry out a specific variant of shutdown. Various other causes may apply in the future. For the same reason, USER_ABORT is not called VTY_COMMAND or SCCP_RESTART -- those names happen to be accurate now. But maybe it will be triggered by the CTRL interface in the future, too, or maybe some other command than VTY 'apply sccp' will need an SCCP shutdown caused by the user; maybe a new vty command 'no msc 0' (just hypothetical). So it makes sense to keep the name as "vague" as it can be while still describing its effect. Similarly for LINK_LOST, I am trying to, within the scope and realm of this FSM, to pick a name that is general enough for the future, without making assumptions on the reason the caller might have. The main difference is that usually SCCP disconnection should still attempt to gracefully release the UE / give time for that to happen initiated by the CN. In contrast, when this LINK_LOST event happens, it means that there is no point in caring about the SCCP connection, because we know, for whichever reason the caller may have, that it will no longer work anyway. So yes, I don't want to fixate on a specific reason the caller has. -- To view, visit https://gerrit.osmocom.org/c/osmo-hnbgw/+/33173 To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings Gerrit-Project: osmo-hnbgw Gerrit-Branch: master Gerrit-Change-Id: Ic0a6fcfb747dc093528ca2bd12a269ad390d465c Gerrit-Change-Number: 33173 Gerrit-PatchSet: 5 Gerrit-Owner: neels <nhofm...@sysmocom.de> Gerrit-Reviewer: Jenkins Builder Gerrit-CC: laforge <lafo...@osmocom.org> Gerrit-CC: pespin <pes...@sysmocom.de> Gerrit-Attention: laforge <lafo...@osmocom.org> Gerrit-Attention: pespin <pes...@sysmocom.de> Gerrit-Comment-Date: Thu, 15 Jun 2023 03:12:03 +0000 Gerrit-HasComments: Yes Gerrit-Has-Labels: No Comment-In-Reply-To: neels <nhofm...@sysmocom.de> Comment-In-Reply-To: laforge <lafo...@osmocom.org> Comment-In-Reply-To: pespin <pes...@sysmocom.de> Gerrit-MessageType: comment
