Control interface introspection of FSMs

[Harald Welte]

Good News, everyone [tm]

Some may have already played with it: The osmo_fsm's already have gained
a VTY interface (see
http://git.osmocom.org/libosmocore/tree/src/vty/fsm_vty.c) some time
ago, which is nice for manual debugging and the like.

However, for automatic testing one would normally want to do something
like the following:
1) send a packet to the implementation under test (IUT)
2) then check if a given FSM has been created, a state has changed,
   a timer is running, etc.
3) go to '1' for the next packet, or wait for a timeout and then
   re-check, ...

I've just introduced a generic CTRL interface for programmatic access to
osmo_fsm.  See https://gerrit.osmocom.org/#/c/2377 for details.

The general idea is that you can send a CTRL command like

GET 1 fsm.FSM_NAME.id.INSTANCE_ID.state
GET 1 fsm.FSM_NAME.id.INSTANCE_ID.timer
GET 1 fsm.FSM_NAME.id.INSTANCE_ID.parent-name
GET 1 fsm.FSM_NAME.id.INSTANCE_ID.dump

Where FSM_NAME is the name of the osmo_fsm (class) and INSTANCE_ID is
the identity of the instance (e.g. the IMSI of a subscriber in the VLR
code).

So in OsmoMSC, something like

GET 1 fsm.vlr_lu_fsm.id.901700123456789.state

would return the string name of the state for the location update FSM of
the given IMSI, e.g. "VLR_ULA_S_WAIT_LU_COMPL_STANDALONE"

I presume Neels will like this. Could be used from osmo-gsm-tester to
not just do "black box testing" from MS to MS or MS to MNCC, but to
actually verify individual states/transitions on all osmo_fsm enabled
elements.  It's of course questionable if an end-to-end test should
care, but I can think of all kinds of other testing (particularly of my
new SIGTRAN work) where it is absolutely useful.

Once the above-mentioned patches are merged, applications with a control
inteface will have this functionality enabled automatically.  I think
this makes osmo_fsm even more useful.  I can imagine use cases not only
related to testing, but also use cases of e.g. user interfaces or
visualization.

Regards,
	Harald

p.s.: In German we say "self praise stinks", but I really think osmo_fsm
is one of the best things happening to the Osmocom cellular projects in
recent years.  Now we just need to convert more code to use it.
-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)