Cross-VM IPC (#916) #1371
Cross-VM IPC (#916) #1371
Conversation
|
The created documentation from the pull request is available at: docu-html |
|
In COM Architecture Meeting on 2025/08/04 we concluded this is a modification of the FR for COM #229. Hence this FR/PR does not constitute a new feature, but creates an updated version of the COM FR. |
FScholPer
requested review from
antonkri,
qor-lb,
johannes-esr and
markert-r
as code owners
FScholPer
requested review from
AlexanderLanin,
MaximilianSoerenPollak and
dcalavrezo-qorix
as code owners
This comment was marked as outdated.
This comment was marked as outdated.
Sorry, something went wrong.
Co-authored-by: ThomasHahn <[email protected]> Signed-off-by: Frank Scholter Peres(MBTI) <[email protected]>
Co-authored-by: ThomasHahn <[email protected]> Signed-off-by: Frank Scholter Peres(MBTI) <[email protected]>
Co-authored-by: ThomasHahn <[email protected]> Signed-off-by: Frank Scholter Peres(MBTI) <[email protected]>
Co-authored-by: ThomasHahn <[email protected]> Signed-off-by: Frank Scholter Peres(MBTI) <[email protected]>
Co-authored-by: ThomasHahn <[email protected]> Signed-off-by: Frank Scholter Peres(MBTI) <[email protected]>
There was a problem hiding this comment.
Pull Request Overview
This PR adds comprehensive documentation for Cross-VM IPC functionality, introducing requirements and specifications for inter-virtual machine communication capabilities.
- Adds stakeholder requirement for cross-VM communication support
- Introduces detailed feature requirements for cross-VM communication mechanisms
- Creates feature documentation with specifications for one-way data sharing and streamed data communication
Reviewed Changes
Copilot reviewed 4 out of 5 changed files in this pull request and generated 4 comments.
| File | Description |
|---|---|
| docs/requirements/stakeholder/index.rst | Adds stakeholder requirement for cross-VM communication |
| docs/features/communication/index.rst | Updates table of contents to include crossvm documentation |
| docs/features/communication/crossvm/requirements/index.rst | Defines detailed functional requirements for cross-VM communication features |
| docs/features/communication/crossvm/index.rst | Provides feature specification, motivation, and implementation details |
Co-authored-by: Copilot <[email protected]> Signed-off-by: Frank Scholter Peres(MBTI) <[email protected]>
Co-authored-by: Copilot <[email protected]> Signed-off-by: Frank Scholter Peres(MBTI) <[email protected]>
Co-authored-by: Copilot <[email protected]> Signed-off-by: Frank Scholter Peres(MBTI) <[email protected]>
|
Still need the approval. Also all github copilot issues where fixed now |
| This feature provides mechanisms for communication and data exchange between processes in different Virtual Machines (VM). | ||
| It includes two classes of communication/data-exchange: | ||
|
|
||
| 1. One-way data sharing into a VM for (vehicle) state read-only for the VM (snapshot state) |
There was a problem hiding this comment.
I might not get the real intention behind this.
As @HartmannNico already mentioned: This should not be a distinct feature request, but rather a change/addition to the existing mw/com/ipc feature.
In the sense, that:
mw::com shall support, that communicating proxies and skeletons might be deployed in processes residing in different VMs!
Thats it.
Because the communication paradigms introduced in mw::com (services, events, fields, service-methods) shall imho stay exact the same. The points under (1) and (2) seem to describe an alternative communication pattern deviating from mw::com?
There was a problem hiding this comment.
Hey @crimson11 you are very late on the last day before deadline. It is already an feature modification request. And already discussed multiple times in the meetings without any feedback. And yes it does not only change to communicate between vms but also other requirements. because the communication paradigms introduced in mw::com (services, events, fields, service-methods) shall imho stay exact the same what is the argument to not extend the current solution?
There was a problem hiding this comment.
Can you explain why these two requirements change the paradigms?
There was a problem hiding this comment.
Hi @FScholPer
Had a short discussion internally and I guess, that @antonkri will reach out to you.
In a nutshell:
Our "preference" would be, that score::mw::com allows/supports, that a corresponding proxy/skeleton pair could be also located in different processes in different VMs.
Technically we would then need to implement either a gateway, which handles the underlying data-exchange between VMs or come up with a setup, where the shared-memory used by score::mw::com between proxy/skeleton is also "visible"/shareable over VM boundaries.
From the user perspective (writing code against the score::mw::com API) it is then transparent, whether the communication is local to the same OS-instance/VM or cross OS-instance/VM.
But it also means, that the event/field/method communication paradigms are identical.
Where I saw the "paradigm" shift/change:
My "interpretation" of the part under (2)
- Support for bi-directional communication via writable data elements by the client
was, that you expect, that a client receiving a "data element", which is an event/field sample in the score::mw::com sense, can update/write to this received "data element" and this change/write is then also visible again to the provider. This is not supported at all by score::mw::com.
There was a problem hiding this comment.
As discussed and agreed in the last architecture workshop this shall be a change request to the existing IPC feature. Currently this is a new subfeature beneath the communication feature.
See notes in https://github.com/orgs/eclipse-score/discussions/1247
Hence, to counteract existing approvals, I'll put a change request.
|
@LittleHuba As it resides also in com and uses the same prefix it is part of com and so lola. The only difference is that I used another folder as this is another usecase as normal IPC. But it is still a modification request and vm to vm is not the only part as you can read. |
|
Ahh okay now I understand the misunderstanding. The summary from the architecture workshop was, that your request boils down to IPC across VM boundaries. |
…-memory-com # Conflicts: # docs/features/communication/index.rst
FScholPer
force-pushed
the
916-fq-non-ipc-shared-memory-com
branch
from
68e5d40 to
0eba313
Compare
|
@LittleHuba @crimson11 as discussed in the last com meeting this pull request does now only contain the cross vm part. The rest will be now in #1715. Please review |
Added Feature Request description and requirements
Frank Scholter Peres [email protected], Mercedes-Benz Tech Innovation GmbH
Provider Information