The CSMP Internet-Draft specifies that group membership information must be stored persistently:
Group membership information MUST be stored in persistent storage so that once a device has been assigned any group it is remembered across reboots.
Currently, the CSMP group handling code keeps group membership information in memory, but there is no OSAL-level interface for storing and restoring this information from platform-specific persistent storage.
Current behavior
Group membership information is maintained at runtime.
However, the code does not currently provide a platform-independent way to:
- load stored group membership information during startup,
- write updated group membership information when assignments change,
- delegate platform-specific persistent storage to the OSAL layer.
As a result, adding persistent group membership requires changes directly in the CSMP logic or platform-specific code paths.
Proposed change
Extend the OSAL interface with group storage functions, for example:
osal_basetype_t osal_read_groups(uint32_t *groups, uint8_t num_groups);
osal_basetype_t osal_write_groups(uint32_t *groups, uint8_t num_groups);
Then call these functions from the relevant CSMP group handling paths:
- read stored group IDs during CSMP service startup,
- write group IDs when a group assignment changes.
Out of scope
This issue does not require implementing actual persistent storage for the existing platform backends.
Existing platform implementations may return OSAL_FAILURE as stubs until platform-specific storage support is added in follow-up changes.
Motivation
The CSMP specification requires group membership information to survive reboots.
Adding the storage interface through OSAL keeps the CSMP group handling code platform-independent and allows each platform to implement persistent storage using its own mechanism, such as flash, file storage, NVM, or another platform-specific backend.
Expected impact
After this change, the codebase should provide the required OSAL API and CSMP integration points for persistent group membership storage.
Actual persistence across reboots will depend on future platform-specific implementations of the new OSAL functions.
The CSMP Internet-Draft specifies that group membership information must be stored persistently:
Currently, the CSMP group handling code keeps group membership information in memory, but there is no OSAL-level interface for storing and restoring this information from platform-specific persistent storage.
Current behavior
Group membership information is maintained at runtime.
However, the code does not currently provide a platform-independent way to:
As a result, adding persistent group membership requires changes directly in the CSMP logic or platform-specific code paths.
Proposed change
Extend the OSAL interface with group storage functions, for example:
Then call these functions from the relevant CSMP group handling paths:
Out of scope
This issue does not require implementing actual persistent storage for the existing platform backends.
Existing platform implementations may return
OSAL_FAILUREas stubs until platform-specific storage support is added in follow-up changes.Motivation
The CSMP specification requires group membership information to survive reboots.
Adding the storage interface through OSAL keeps the CSMP group handling code platform-independent and allows each platform to implement persistent storage using its own mechanism, such as flash, file storage, NVM, or another platform-specific backend.
Expected impact
After this change, the codebase should provide the required OSAL API and CSMP integration points for persistent group membership storage.
Actual persistence across reboots will depend on future platform-specific implementations of the new OSAL functions.