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 <nhofmeyr(a)sysmocom.de>
Gerrit-Reviewer: Jenkins Builder
Gerrit-CC: laforge <laforge(a)osmocom.org>
Gerrit-CC: pespin <pespin(a)sysmocom.de>
Gerrit-Attention: laforge <laforge(a)osmocom.org>
Gerrit-Attention: pespin <pespin(a)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 <nhofmeyr(a)sysmocom.de>
Comment-In-Reply-To: laforge <laforge(a)osmocom.org>
Comment-In-Reply-To: pespin <pespin(a)sysmocom.de>
Gerrit-MessageType: comment