| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
| |
FSMs with identical names confuse the script, so at least warn about them.
IMHO we should also have different names for each FSM, so not bothering to make
the script safe against identical naming.
Change-Id: I4fe7e85d2fdf23e2ba964f3b47be1954edc63cef
|
| |
|
|
|
|
|
| |
If an FSM transitions to a state that actually belongs to a different FSM,
print an error and mark it red, instead of exiting with exception.
Change-Id: I73d95a0c65ca1ea586ad55234610671a53d6220f
|
| |
|
|
|
|
|
|
|
|
| |
Do some more mad hacking to only detect event triggers if event names actually
appear in if() or case: statements. Also combine events in consecutive 'case'
statements.
When will this madness stop?
Change-Id: Iabaaab57f0d1687607eaaa4e09c7c2439fbd7a25
|
| |
|
|
|
|
|
| |
Most arrows draw state transitions, but some want to show that an event is
delivered to a state. Mark those with a "halfopen" arrow head.
Change-Id: Ib07380894a6d513896c9135f175ecbf653a23eec
|
| |
|
|
|
|
|
| |
When some edges have no label, it is sometimes hard to interpret which label
belongs to which edge. Adding a '-' default label clarifies the edge labeling.
Change-Id: I3a10b615288107e8fc12ffdbbe0099cf51abe94f
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Hacked as it is, fsm-to-dot is capable of detecting action functions
transitioning to states that are not allowed according to the FSM definition
struct.
Draw those in red and output a warning.
Found these osmo-bsc gscon errors with this patch:
ERROR: gscon_fsm_active() triggers a transition to ST_WAIT_HO_COMPL, but this is not allowed by the FSM definition
ERROR: gscon_fsm_wait_ho_compl() triggers a transition to ST_WAIT_MDCX_BTS_HO, but this is not allowed by the FSM definition
Related: OS#3109
Change-Id: Ic6319a958b3c7247510c1930bac8b02b95f9dcf2
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Strip comments from function bodies before matching on event names.
In osmo-bsc's gscon FSM, there often are event names in comments. The naive
parsing of fsm-to-dot.py mistakes these as events causing state transitions,
but the comments are just explaining how states interact.
Makes me reconsider parsing the C with clang instead, but I got away with a
dirty hack once more.
Change-Id: I56d70ae14d363f7ca655dced16d93d795b3f940d
|
| |
|
|
|
|
|
| |
In osmo-bsc's new gscon FSM, there is an osmo_fsm_inst_state_chg() from
ST_ACTIVE to ST_ACTIVE. Avoid an exception triggering on this simple fact.
Change-Id: I420c7be84e3af555cc5e8bddbff7261013348375
|
| |
|
|
| |
Change-Id: I196033e44d50ebb73cf9b44cbdc94a2b8b4f98ce
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Combine the C source file name and the string name into the fsm's internal name
token, and use it in most places instead of the plain struct name: osmo-bsc's
new FSMs have identical struct names in each static c context.
Output in a file name that includes all of these more detailed name tokens.
Also parse '(1 << EVENT)' as event names.
Note that besides this patch, there are also some tweaks to the osmo-bsc patch
that improve the fsm-to-dot experience...
- call fsm-to-dot for single files to avoid name conflicts, or rename each
struct as a unique name.
- Add comments for the event name a callback is intended for, so that not all
transitions are interpreted as TEARDOWN (because it is invoked in common
error handling, which causes the script to interpret it as the causing
event). (or change the event-checking if into a switch that names the valid
event and has a default case for all others.)
Change-Id: Ib60df7fd19efc99ba9fe797f14c0e3239c4bea20
|
|
|
Add a first version of a python script that tries to analyze .c source files to
draw graphs of osmo_fsm implementations. So far it uses quick-and-dirty
regexes.
Change-Id: I155f57a608d600f59aedfd27ef66eb9772c124e7
|
