ssm: Fix up the SSM documentation a bit

This commit is contained in:
Benjamin Berg 2021-04-23 12:10:58 +02:00 committed by Benjamin Berg
parent 04f6cac7ec
commit c4ae89575a

View file

@ -31,27 +31,22 @@
* @short_description: State machine helpers * @short_description: State machine helpers
* *
* Asynchronous driver design encourages some kind of state machine behind it. * Asynchronous driver design encourages some kind of state machine behind it.
* In most cases, the state machine is entirely linear - you only go to the * #FpiSsm provides a simple mechanism to implement a state machine, which
* next state, you never jump or go backwards. The #FpiSsm functions help you * is often entirely linear. You can however also jump to a specific state
* implement such a machine. * or do an early return from the SSM by completing it.
* *
* e.g. `S1` `S2` `S3` `S4` * e.g. `S1` `S2` `S3` `S4`
* *
* `S1` is the start state * Where `S1` is the start state.
* There is also an implicit error state and an implicit accepting state
* (both with implicit edges from every state).
* *
* You can also jump to any arbitrary state (while marking completion of the * Use fpi_ssm_new() to create a new state machine with a defined number of
* current state) while the machine is running. In other words there are * states. Note that the state numbers start at zero, making them match the
* implicit edges linking one state to every other state. * first value in a C enumeration.
*
* To create an #fpi_ssm, you pass a state handler function and the total number of
* states (4 in the above example) to fpi_ssm_new (). Note that the state numbers
* start at zero, making them match the first value in a C enumeration.
* *
* To start a ssm, you pass in a completion callback function to fpi_ssm_start() * To start a ssm, you pass in a completion callback function to fpi_ssm_start()
* which gets called when the ssm completes (both on error and on failure). * which gets called when the ssm completes (both on failure and on success).
* Starting a ssm also takes ownership of it. * Starting a ssm also takes ownership of it and it will be automatically
* free'ed after the callback function has been called.
* *
* To iterate to the next state, call fpi_ssm_next_state(). It is legal to * To iterate to the next state, call fpi_ssm_next_state(). It is legal to
* attempt to iterate beyond the final state - this is equivalent to marking * attempt to iterate beyond the final state - this is equivalent to marking
@ -59,7 +54,6 @@
* *
* To mark successful completion of a SSM, either iterate beyond the final * To mark successful completion of a SSM, either iterate beyond the final
* state or call fpi_ssm_mark_completed() from any state. * state or call fpi_ssm_mark_completed() from any state.
* This will also invalidate the machine, freeing it.
* *
* To mark failed completion of a SSM, call fpi_ssm_mark_failed() from any * To mark failed completion of a SSM, call fpi_ssm_mark_failed() from any
* state. You must pass a non-zero error code. * state. You must pass a non-zero error code.
@ -69,13 +63,9 @@
* which operations to perform (a switch statement is appropriate). * which operations to perform (a switch statement is appropriate).
* *
* Typically, the state handling function fires off an asynchronous * Typically, the state handling function fires off an asynchronous
* communication with the device (such as a libsub transfer), and the * communication with the device (such as a USB transfer), and the
* callback function iterates the machine to the next state * callback function iterates the machine to the next state
* upon success (or fails). * upon success (or fails).
*
* Your completion callback should examine the return value of
* fpi_ssm_get_error() in order to determine whether the #FpiSsm completed or
* failed. An error code of zero indicates successful completion.
*/ */
struct _FpiSsm struct _FpiSsm