Change in libosmocore[master]: fsm: support graceful osmo_fsm_inst_term() cascades

Neels Hofmeyr gerrit-no-reply at lists.osmocom.org
Tue Apr 2 03:48:17 UTC 2019


Neels Hofmeyr has posted comments on this change. ( https://gerrit.osmocom.org/13392 )

Change subject: fsm: support graceful osmo_fsm_inst_term() cascades
......................................................................


Patch Set 4:

(1 comment)

https://gerrit.osmocom.org/#/c/13392/4//COMMIT_MSG
Commit Message:

https://gerrit.osmocom.org/#/c/13392/4//COMMIT_MSG@33
PS4, Line 33: Note: at least osmo-msc's msc_vlr_tests' expected output needs to be adjusted
            : after merging this, because of logging changes for FSM deallocations
> The main cause is that the order of deallocation changes. […]
and actually also, what was a simple "Deallocated" logging before, may now become "Listing for deallocation with [other FSM inst id]", and there is s/"Terminating"/"Terminating in cascade".
see http://git.osmocom.org/osmo-msc/commit/?h=neels/ho&id=0a5bd401af092019cdf65aa1a1131cebefe96b76

I think it is only mildly bad, the bad thing rather that this deallocation logging is in that osmo-msc test output in the first place. We've had a number of occasions where something affected that test output and adjusted it.

But since I want to log state transitions, I also have to include deallocation logging, no way around it in the current FSM instance log category and level scheme (besides grepping output maybe)

I have also considered a number of times to detach those tests from osmo-msc.git, or even lose them entirely; because they continuously introduce a bit of work like this on and off, and considerably blow up the git diffs, and also you don't like them ;) ... But in my reckoning the benefits still outweigh the drawbacks: it is often quite useful to track exactly how the logging in osmo-msc changes, which the ttcn3 tests don't (and can't) provide, and the fake time that ttcn3 can't provide makes for an ultra short dev cycle when hunting bugs. Minuses are complex hacks to make them work in a dry-run way, blown up git diffs, test failures from trivial logging changes. Am open to discussion there.



-- 
To view, visit https://gerrit.osmocom.org/13392
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings

Gerrit-Project: libosmocore
Gerrit-Branch: master
Gerrit-MessageType: comment
Gerrit-Change-Id: I8eda67540a1cd444491beb7856b9fcd0a3143b18
Gerrit-Change-Number: 13392
Gerrit-PatchSet: 4
Gerrit-Owner: Neels Hofmeyr <nhofmeyr at sysmocom.de>
Gerrit-Reviewer: Jenkins Builder (1000002)
Gerrit-Reviewer: Neels Hofmeyr <nhofmeyr at sysmocom.de>
Gerrit-CC: Harald Welte <laforge at gnumonks.org>
Gerrit-Comment-Date: Tue, 02 Apr 2019 03:48:17 +0000
Gerrit-HasComments: Yes
Gerrit-HasLabels: No
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/gerrit-log/attachments/20190402/3a93b850/attachment.html>


More information about the gerrit-log mailing list