Lib: SMF: transition on return code rather than smf_set_state()

[glenn-andrews]

Looking at other state machine frameworks, they often use a return code to signal the framework to begin transition, rather than the transition happening directly in smf_set_state() as we have now.

smf_run_state() would handle the transition after the function returns, and smf_set_state() would merely set a pointer to the next state and return the code to indicate a transition is requested.

We're already using a return code to signal event propagation in hierarchical state machines, so it makes sense to unify all SMF actions in a return code.

I've written the code and it works, but when I started modifying the USB-C code I discovered most of the state machines do not transition directly while being executed by smf_run_state(), but transitions are triggered from other functions, and entry/exit actions are immediately executed. I'd have to either completely refactor USB-C to accommodate that (which I don't want to do) or create an smf_force_transition() function which performs the same function as smf_set_state() did, at which point is it even worth making the change to the code at all?

I'd appreciate advice on this.

[glenn-andrews]

@keith-zephyr @sambhurst @maass-hamburg any thoughts?

[glenn-andrews]

Also see the Options section here: #83659

[keith-zephyr]

I don't immediately a net benefit of making such a significant change. But please share links to other state machine frameworks that utilize the return code for state transitions so I can look compare implementation patterns.

[glenn-andrews]

Quantum Leaps is the first one that springs to mind: the Q_TRAN() macro returns Q_RET_TRAN to signal the transition.

It appears the Boost Statechart library does something similar within it's transit class. I'm not so sure about that one, though.