Skip to content

Commit 28344b7

Browse files
committed
Clarify when the ops value is reset
In the Functionality Overview, clarify the points at which the accumulated ops for an interruptible multi-part operation are reset.
1 parent 4c6cdda commit 28344b7

File tree

1 file changed

+6
-2
lines changed

1 file changed

+6
-2
lines changed

doc/crypto/overview/functionality.rst

Lines changed: 6 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -250,7 +250,7 @@ There are three components in an interruptible operation:
250250

251251
An application can set an overall *maximum ops* value, that limits the *ops* performed within any interruptible function called by that application. The current *maximum ops* value can also be queried. If the *maximum ops* is not set by an application, interruptible functions will not return until the operation is complete.
252252

253-
Each interruptible operation also provides a function to report the cumulative number of *ops* used by the operation. This value is only reset when the operation object is set up for a new operation, which permits the value to be queried after an operation has finished.
253+
Each interruptible operation also provides a function to report the cumulative number of *ops* used by the operation. This value is only reset when the operation is aborted, or when an operation object is set up for a new operation. This permits the final value to be queried after an operation has finished successfully.
254254

255255
Interruptible operations follow a common pattern of use, which is shown in :numref:`fig-interruptible`.
256256

@@ -281,6 +281,8 @@ The typical sequence of actions with a interruptible operation is as follows:
281281
#. **Setup:** Start a new interruptible operation on an *inactive* operation object.
282282
Each interruptible operation object will define one or more setup functions to start a specific operation.
283283

284+
The accumulated *ops* value for the operation is reset to zero.
285+
284286
On success, a setup function will put an interruptible operation object into an *active* state.
285287
On failure, the operation object will remain *inactive*.
286288

@@ -294,7 +296,7 @@ The typical sequence of actions with a interruptible operation is as follows:
294296
An application needs to repeat this step until the completion function returns with a success or an error status.
295297

296298
#. **Abort:** An interruptible operation can be aborted at any stage during its use by calling the associated ``psa_xxx_iop_abort()`` function.
297-
This will release any resources associated with the operation and return the operation object to the *inactive* state.
299+
This will release any resources associated with the operation, return the operation object to the *inactive* state, and reset the accumulated *ops* value to zero.
298300

299301
Any error that occurs to an operation while it is in an *active* state will result in the operation entering an *error* state.
300302
The application must call the associated ``psa_xxx_iop_abort()`` function to release the operation resources and return the object to the *inactive* state.
@@ -348,6 +350,8 @@ In the following sequence, detail is only provided where actions behave differen
348350
#. **Begin-setup:** Start a new interruptible operation on an *inactive* operation object.
349351
Each operation object will define one or more setup functions to start a specific operation.
350352

353+
The accumulated *ops* value for the operation is reset to zero.
354+
351355
On success, an operation object enters a *setup* state.
352356
On failure, the operation object will remain *inactive*.
353357

0 commit comments

Comments
 (0)