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.

[henrikbrixandersen]

It has always seemed a bit weird to me that the _enter function of the new state is called directly when smf_set_state() is called and not after the current state function returns, but I do see the problem with how the USB-C state machine uses the framework in this regard.

In my use, I always call smf_set_state() from within state functions, but not only _run - also from _entry functions if the entered state should automatically transition to another state. Would this proposed change allow for calling smf_set_state() from _entry functions?

[glenn-andrews]

Yes, both entry and run actions return what the state machine framework should do, which in the case of an entry action would be either transition, or call the next entry action (if any).

Run actions have three options: transition, call the parent run action (if any), or do nothing.