You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: doc/crypto/overview/functionality.rst
+6-2Lines changed: 6 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -250,7 +250,7 @@ There are three components in an interruptible operation:
250
250
251
251
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.
252
252
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.
254
254
255
255
Interruptible operations follow a common pattern of use, which is shown in :numref:`fig-interruptible`.
256
256
@@ -281,6 +281,8 @@ The typical sequence of actions with a interruptible operation is as follows:
281
281
#. **Setup:** Start a new interruptible operation on an *inactive* operation object.
282
282
Each interruptible operation object will define one or more setup functions to start a specific operation.
283
283
284
+
The accumulated *ops* value for the operation is reset to zero.
285
+
284
286
On success, a setup function will put an interruptible operation object into an *active* state.
285
287
On failure, the operation object will remain *inactive*.
286
288
@@ -294,7 +296,7 @@ The typical sequence of actions with a interruptible operation is as follows:
294
296
An application needs to repeat this step until the completion function returns with a success or an error status.
295
297
296
298
#. **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.
298
300
299
301
Any error that occurs to an operation while it is in an *active* state will result in the operation entering an *error* state.
300
302
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
348
350
#. **Begin-setup:** Start a new interruptible operation on an *inactive* operation object.
349
351
Each operation object will define one or more setup functions to start a specific operation.
350
352
353
+
The accumulated *ops* value for the operation is reset to zero.
354
+
351
355
On success, an operation object enters a *setup* state.
352
356
On failure, the operation object will remain *inactive*.
0 commit comments