C. Variation in system design parameters¶
Depending on the system design and product requirements, an implementation is permitted to collapse a chain of transitions for a component, where this does not remove information that is required by the update client, or compromise other system requirements. This can result in some states and transitions being eliminated from the state model for that component’s firmware store.
An implementation is also permitted to provide either volatile or persistent behavior for the WRITING, CANDIDATE, FAILED, and UPDATED states. See also Volatile states. Volatile states cause additional transitions to occur at reboot.
Table 7 lists a sample of the possible variations that are illustrated in this appendix, as well as the complete state model provided in Programming model.
Reboot required |
Trial required |
Staging type a |
Description |
---|---|---|---|
Yes |
Yes |
Non-volatile |
See complete model |
Yes |
Yes |
Volatile |
|
Yes |
No |
Non-volatile |
See no-trial model |
Yes |
No |
Volatile |
|
No |
Yes |
Non-volatile |
See no-reboot model |
No |
Yes |
Volatile |
|
No |
No |
Non-volatile |
|
No |
No |
Volatile |
If the staging type is volatile, then CANDIDATE, WRITING, FAILED, and UPDATED states are volatile.
If the staging type is non-volatile, then CANDIDATE state is non-volatile, and it is implementation defined whether WRITING, FAILED, and UPDATED states are volatile.
C.1. Component with non-volatile staging¶
A component that does not have volatile staging will maintain the CANDIDATE component state across a reboot, and can optionally maintain the WRITING, FAILED, and UPDATED component states across a reboot.
Additional reboot transitions for states with optional volatility are indicated with ‘†’ and ‘‡’ marks on the state, and described in the figure legend.
See Component with volatile staging for example state models for a component that has volatile staging.
C.1.1. Component that requires a reboot, but no trial¶
If a component does not require testing before committing the update, the the TRIAL and REJECTED states are not used.
The reboot that installs the firmware will transition the component to UPDATED on success, or FAILED on failure, unless the target state is volatile, in which case the reboot will transition the component to READY.
The
accept
operation is never used.The
reject
operation is only used to abandon an update that has been STAGED.
The simplified flow is shown in Figure 9.
C.1.2. Component that requires a trial, but no reboot¶
If a component does not require a reboot to complete installation, the STAGED and REJECTED states are not used.
The
install
operation will complete the installation immediately, transitioning to TRIAL if successful.The
reject
operation from TRIAL state does not require a reboot to complete. Areject
operation from TRIAL states transitions directly to FAILED.
The simplified flow is shown in Figure 10:
Implementation note
There is no ability for the update service to automatically reject a TRIAL, because a reboot does not affect this component’s installation.
C.1.3. Component that requires neither a reboot, nor a trial¶
If a component does not require a reboot to complete installation, and does not require testing before committing the update, then the STAGED, TRIAL, and REJECTED states are not used.
The
install
operation will complete the installation immediately, transitioning to UPDATED if successful.The
accept
andreject
operations are not used.
The simplified flow is shown in Figure 11:
C.2. Component with volatile staging¶
A component that has volatile staging does not maintain the WRITING, CANDIDATE, FAILED, and UPDATED component states across a reboot.
In each case the state model is very similar to the associated state model for a component with non-volatile staging, except that a reboot now affects almost all states:
WRITING, CANDIDATE, and FAILED states will always revert to READY, discarding any image that had been prepared or rejected.
UPDATED state is progressed to READY.
Existing reboot transitions from STAGED, TRIAL, and REJECTED, that go to FAILED in the non-volatile-staging model, are reverted to READY.
The existing reboot transition from STAGED to UPDATED for a successful installation in the ‘no trial’ model, transitions to READY.
The modified flows are shown in the following figures:
Modified reboot transitions are shown explicitly in the diagrams.
New reboot transitions are indicated with ‘*’, ‘†’, and ‘‡’ marks on the state, and described in the diagram legend.