Persistency CFT [2024-01-23]

[johannes-esr]

Participants

• Johannes Glamsch
• Anton Krivoborodov
• Ulrich Huber
• Henri Bragge
• Lars Bauhofer
• Vinod Reddy
• Arvid Sievert

Agenda

1. Introduction Round
2. Definition of Goals until Architecture Workshop
3. Open Discussion of Scope of Persistency Feature

Meeting Minutes

2. • Filled out template of https://eclipse-score.github.io/score/process/guidance/contribution_request/templates/feature_request_template.html, especially Abstract/Motivation/Rationale
   • Detailed Specification/Requirements to be done probably later
   • "Code First" approach
3. • Persistency consists of multiple sub-features
     • Key-Value Storage
       • Key-Value Storage is needed because there are (legacy) applications which require a KVS
       • There are multiple Key-Value Storages allowed per application
       • There must be an update mechanism from different versions of a KVS to another version
       • When are modifications persistet? Configurable?
       • The same KVS should be read/writeable from C++ & Rust.
       • Supported Datatypes: Primitive Datatypes & Non-Primitive Datatypes; To be coordinated with IPC/Communication CTF, to use the same datatypes
       • Tooling to modify/access content of KVS "from the outside"
       • KVS should store default values
       • Integrity of the KVS should be checked
     • File Storage
       • "File Storage Persistency Feature":
         • Additional tooling regarding integrity checking & updating
       • "File Storage OSAL":
         • Can just language native APIs be reused?
         • Safety certification of C++ stdlib / Rust lib?
         • Re-implementation of language APIs probably needed due to testability
         • Enforcement of access rights is up to the OS

-> @LittleHuba to create two PRs for each Sub-Feature individually

[LittleHuba]

I created the two PRs:

• KVS persistency: Feature request for KVS #219
• File Access persistency: Feature request for File Access #220