LoLa / mw::com support for C and Classic AUTOSAR

[atharvat17]

We request S-CORE support for a C and Classic AUTOSAR implementation of LoLa / mw::com, so applications on a safety core or in Classic AUTOSAR software can act as normal publishers and subscribers. It should support communication between these applications and with LoLa-enabled applications in other domains.

The target environments have these constraints:

• They use freestanding C and static memory allocation, without a C++ runtime.
• They have no filesystem or runtime JSON configuration. Classic AUTOSAR software uses generated static configuration instead.
• Current LoLa uses filesystem directories and flag files for service discovery, watches them using inotify, and creates or opens named OS shared-memory resources. These mechanisms are not available directly on the targets.
• They commonly provide only 32-bit atomic operations, while current LoLa event-slot control uses 64-bit atomic operations.
• Current LoLa DATA and CTRL shared-memory layouts are C++ implementation details; there is no supported C ABI through which a target can safely interpret and use them.
• S-CORE's supported-programming-languages requirement, stkh_req__dev_experience__prog_languages, currently lists C++ and Rust, but not C. Its communication requirement, feat_req__com__multi_lang, requires a public communication API for every supported programming language. We request that S-CORE add C support for LoLa / mw::com, including use in Classic AUTOSAR software.

This is not a request for an extern "C" wrapper around the existing C++ API. These targets cannot run the existing C++ runtime or depend on its dynamic configuration and shared-memory object layouts.

We request feedback on whether S-CORE can support this C and Classic AUTOSAR LoLa / mw::com capability.

[FScholPer]

@atharvat17 S-CORE does only target big ecus also autosar compliance can not be done as it would require autosar ip. For support of classic usecases please check https://github.com/eclipse-openbsw/openbsw

[btirunagaru]

@FScholPer i think the ticket was misunderstood - what we intent to explain is the environment rather the compliance of a standard.
We want MW:COM to be deployed on a Hardware that runs RTOS with C support. (where the C++ is not used).

[crimson11]

@FScholPer
Reopening the discussion.
I was in contact with @btirunagaru - I support his case.
Currently we have "official" support for C++/Rust language bindings for score::mw::com.
We also have still a "gap" right now, as we don't have an "IDL" and ABI compatible datatypes to be efficiently exchanged in score::mw::com zero-copy shared-memory binding ... this just as a side-note.

Also within BMW I see use cases coming up, where you have "shared memory" between a high-performance CPU running a full SCORE stack and some microcontroller with some basic RT OS and high ASIL-level.
In such a setup communicating over shared memory using score::mw::com with LoLa binding looks like an attractive option.

What would need to be done by score::mw::com: Choose datatypes for the control-structures within the shared-memory, which have a defined/clear ABI, so that "the other side" can interact.
We are already going into the direction in the sense, that we are NOT using any STL datatypes (where ABI is not defined/depends on the STL implementation) anymore, but our own, which we control. So the tiny next step would be to make sure, that the ABI for them is crystal clear (can be expressed as C data types). That's it.

Writing a C99 API on top - which "paraphrases" the existing C++/Rust user facing/public APIs for score::mw::com - is then the bigger effort. Whether it makes sense to provide/contribute and maintain this also in SCORE repo ... IDK, but why not, when someone is willing to do this effort?