ndevillard
commented
2 years ago Should we separate out all items related to differences with v0.7 in their own dedicated appendix? We should not expect most readers to be familiar with v0.7.
Open athoelke opened 2 years ago
ndevillard
commented
2 years ago Should we separate out all items related to differences with v0.7 in their own dedicated appendix? We should not expect most readers to be familiar with v0.7.
athoelke
commented
2 years ago Should we separate out all items related to differences with v0.7 in their own dedicated appendix? We should not expect most readers to be familiar with v0.7.
I have provided links to the v0.7 definitions in the posting above, rather than copy the text out and repeat it here
The v0.7 specification defines a number of key terms and concepts for the API: see 3. Terminology. However, some of these terms are used ambiguously, or in different ways in other parts of the specification.
In v1.0 the definitions need to be clarified (if required) and used consistently. In addition, a change in focus for the state model requires one or two additional terms (see #1).
We propose to use the following concepts, please comment if you have a better term/name for the concept than used here.
Firmware Image Creator, Update Server, Update Client, Update Service, Bootloader
These are entities involved in a typically Firmware update process, and summarised in this context graphic:
Update client matches the term in v0.7
The Installer from v0.7 is a useful abstraction as the processor of firmware images - the flexibility in how it is implemented makes it less clear if it is helpful in the API definition.
Image or Firmware image
As in v0.7, this is the binary object that is being transferred by the API from the Update client to the Update service. The v0.7 definition will be retained.
A Firmware image is the 'unit of update'.
Component
This is a logical part of the device which needs a Firmware image. Each Firmware image is designed for exactly one of these Components.
Although a Component might have a 1:1 correspondence with a physical processor in the system, other mappings are possible:
Component Id
This replaces the concept of Image ID (see Image storing) in v0.7. The use of Image ID terminology is inconsistent, and the term suggests that this is identifying a specific instance of a firmware image, then the intention is that this identifies which Component the image is for: the type of the image.
The Component identifier is a small numerical value, that precisely identifies the Component on this device. The identifier values are typically allocated by the device developer or integrator, and might be used in metadata within the update process, or translated via a mapping configured in the Update client.
Firmware Store
This is the location where firmware images are stored. Conceptually the Firmware store is between the Update service and the Bootloader, which use it to manage the Firmware update process.
The API presents a separate Firmware store for each Component. Each Component's firmware store can have one or more images present. The state of the store determines how those images are used, and what is required to proceed with a firmware update.
Manifest
As in v0.7, this is firmware image metadata that is external to the image.