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 Hofmeyr gerrit-no-reply at lists.osmocom.orgPatch Set 1: Code-Review+1 (7 comments) +2 for the dead code removal. Also added some general comments related to OS#3103. https://gerrit.osmocom.org/#/c/8054/1/src/libmsc/a_reset.c File src/libmsc/a_reset.c: Line 32: #define RESET_RESEND_TIMER_NO 16/* See also 3GPP TS 48.008 Chapter 3.1.4.1.3.2 */ (space before comment) Line 60: static void fsm_conn_cb(struct osmo_fsm_inst *fi, uint32_t event, void *data) Looks like you can also drop this cb function. So, there is no way to transition back to ST_DISC? How is a disconnect noticed, by terminating the FSM? Line 71: struct a_reset_ctx *reset = (struct a_reset_ctx *)fi->priv; I don't see anywhere pointing fi->priv to a_reset_ctx. Something tells me you haven't tested reset ack timeout and Reset resending? Line 74: LOGPFSML(reset->fsm, LOGL_NOTICE, "(re)sending BSSMAP RESET message...\n"); (rather use fi; of course they should be identical, just is more like the usual fi code flow) Line 90: .in_event_mask = (1 << EV_RESET_ACK), we explicitly allow repeated RESET ACKs? Is that a real thing? Line 122: reset->priv = priv; re priv, see here. Line 145: osmo_fsm_inst_dispatch(reset->fsm, EV_RESET_ACK, reset); re priv, this uses event's data pointer instead of priv. -- To view, visit https://gerrit.osmocom.org/8054 To unsubscribe, visit https://gerrit.osmocom.org/settings Gerrit-MessageType: comment Gerrit-Change-Id: I8e489eb494d358d130e51cb2167929edeaa12e92 Gerrit-PatchSet: 1 Gerrit-Project: osmo-msc Gerrit-Branch: master Gerrit-Owner: dexter <pmaier at sysmocom.de> Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: Neels Hofmeyr <nhofmeyr at sysmocom.de> Gerrit-HasComments: Yes