Basic multi IPC adapter project structure #3

piotrchodorowski · 2025-09-07T11:40:12Z

No description provided.

* Add design principles * Add Runtime & RuntimeBuilder * Add three variants for the Sample smart pointer design * Extended variant 2 to be "complete"

* Incorporate Sample[Ptr|MaybeUninit] traits As discussed in the workshop on Apr 3rd, this change adds all traits for samples. * Remove adapter parameter from sample traits Since the traits actually doesn't need to be parameterized with the adapter type, we remove it to prevent the same type from implementing these traits for different adapter types. * Make DerefMut supertrait of SampleMaybeUninit Since SampleMaybeUninit operates on potentially uninitialized data we can enable reusing all non-consuming methods of MaybeUninit. This of course imposes the restriction on the implementation to also include MaybeUninit. However, this is anyway needed in all but the most trivial eample implementations, so this shouldn't be a huge burden. * Comment on Reloc trait and add copyright headers

* Add Subscriber trait with all agreed receive variants * Move demo interface code to a separate module

Split crates so that they match a real use case, consisting of * Generated interface declaration(s) * Generated binding code * Upper level API * Binding specific common code * Application See the .puml for a overview

n Subscriber, we need to make sure that the returned sample pointers as well as the types they wrap never outlive the lifetime of the subscriber. Constrain the methods accordingly.

* Introduce service discovery on consumer side * Introduce subscribe/unsubscribe * Introduce offer/unoffer on producer side * Revise receive calls on subscription side

By merging the generated interface and the runtime specific code and turning Builder into a parameterized trait, we can avoid violating the orphan rule. This enables moving a lot of stuff to the non-generated part of the code, only keeping what really needs to be generated.

This is actually the right place. Unfortunately, we cannot add treit methods to the Runtime trait as they would be too generic, requiring _any_ implementor of the Interface trait to be instantiable, not just the ones generated.

Instead of having to create a builder from a descriptor, make the descriptor trait a supertrait of the ConsumerBuilder, and make ServiceDiscovery return a list of builders immediately.

* create_provided_service -> producer_builder * find_instance -> find_service * available_services -> available_service_instances

Merge Rust API draft into incubator

The test tries to mimic a common pattern, which is the processing of incoming subscription data via an async function. The resulting Future shall be compatible with the spawn function of common executors (tokio in this case). This means that the Future itself and its output are Send + 'static. The test requires fixing the lifetime bounds of receive. In addition, it is (for now) not possible to use a trait for the receiving container. Instead, a concrete class is used.

This feels more natural and makes the API less awkward to use.

Clippy revealed that tere still was a lifetime issue in the allocate function. While this API is anyway still unfinished, it's good to already fix that so that we already see this during API development.

Add test for async consumer use case

pawelrutkaq

Bedis enttry point I don't have more questions I think for this PR

pawelrutkaq · 2025-09-08T10:22:54Z

com-api/com-api/src/prelude.rs

+    Builder, Consumer, ConsumerBuilder, ConsumerDescriptor, InstanceSpecifier, Interface,
+    OfferedProducer, Producer, ProducerBuilder, Reloc, Result, SampleContainer, SampleMaybeUninit,
+    SampleMut, ServiceDiscovery, Subscriber, Subscription,
+};


We shall make this more usable imho and easy to use + self describing.
I would do Runtime/Adapter entry point

#[cfg(feature = "iceoryx")] pub type RuntimeImpl = com_api_runtime_iceoryx::RuntimeBuilderImpl; #[cfg(feature = "lola")] pub type RuntimeImpl = com_api_runtime_lola::RuntimeBuilderImpl; // This is checker that whatever You bound into alias has implemented `Rutime` trait from concepts. This `Runtime` trait // shall later have ie Publisher type imho. struct RuntimeChecker<T: Runtime>{_d: PhantomData<T>} impl<> RuntimeChecker<RuntimeImpl > {}

@awillenbuecher-xq-tec whats yuor opinion ?

I don't think there's really a difference between pub type X = a::b::X; and pub use a::b::X;, or is there? And I would be careful with renaming RuntimeBuildImpl to RuntimeImpl, that's a bit confusing.

But I agree that not every trait and type should be re-exported in the crate-level namespace, and the producer and consumer traits should probably be separated into their own modules.

My plan is to do another big renaming PR after that which will cover all adapter specific and generic stuff with some prefix/suffix to avoid any confusion.
In this case something like: LolaRuntimeBuilderImpl, IceoryxRuntimeBuilderImpl, RuntimeBuilderConcept.

It is intentional to dont to that in this PR.

For me here is important that there is SINGLe defined NAME for accessing "Runtime". The Impls at the end can be any name and shall not be directly bounded to the NAME users use in their code. But I understand that will come with "rename/refactor" PR, then its fine.

.gitignore

awillenbuecher-xq-tec · 2025-09-08T11:25:58Z

com-api/com-api-runtime-iceoryx/Cargo.toml

+license = "Apache-2.0"
+
+[dependencies]
+com-api-concept = { path = "../com-api-concept", features = ["iceoryx"] }


The four com-api* crates should probably all be part of a Cargo workspace. For this, create a Cargo.toml file under inc_mw_com/com-api/ and list the four crates as members. The workspace Cargo.toml should also list all dependencies used by the crates:

[workspace.dependencies] com-api-concept = { path = "com-api-concept" } futures = "0.3"

and each crate Cargo.toml should refer to them like this:

[dependencies] com-api-concept = { workspace = true, features = ["iceoryx"] } [dev-dependencies] futures.workspace = true

This ensures that all crates always use the same version of shared dependencies.

Workspace was the initial idea but I run into a problem that dependencies cant be optional under workspace.
Due to that we can't have both lola and iceoryx dependency within workspace at same time because it will be then build together and we will lead to activate both features.
Due to that we can have workspace only without specific runtimes which brakes the whole idea and creates mess and thats why I removed the workspace from this project.

at the end, S-CORE does use bazel only....

S-CORE does use bazel only

But rust-analyzer uses Cargo, and writing Rust without IDE support isn't fun 😉

com-api/com-api-concept/src/lib.rs

com-api/com-api/src/lib.rs

com-api/com-api-runtime-iceoryx/src/lib.rs

pawelrutkaq

For me fine as other points will be in other PR if I get right. For me this can now go to S-CORE and You can prepare renaming/polishin interface PR as follow up

pawelrutkaq · 2025-09-08T14:41:16Z

in S-CORE PR template please write intention and what is done and whats not so it's clear there.

awillenbuecher-xq-tec

Just two small changes necessary, seems good otherwise.

com-api/examples/com-api-gen/com-api-gen-iceoryx/Cargo.toml

com-api/examples/com-api-gen/com-api-gen-lola/Cargo.toml

darkwisebear and others added 20 commits April 17, 2025 09:16

Proceedings from the workshop on Mar 27th

3cc6fc8

* Add design principles * Add Runtime & RuntimeBuilder * Add three variants for the Sample smart pointer design * Extended variant 2 to be "complete"

Proceedings from workshop on Apr 22nd

83b4261

Further proceedings

8cd6da7

Add intermediate solution using explicit make_instance method

077e99a

Updates from workshop #5

9d313cf

* Add Subscriber trait with all agreed receive variants * Move demo interface code to a separate module

Rearrange crates to fit real use case

1eaf4de

Split crates so that they match a real use case, consisting of * Generated interface declaration(s) * Generated binding code * Upper level API * Binding specific common code * Application See the .puml for a overview

Constrain lifetimes of sample ptrs and referenced types

6e59025

n Subscriber, we need to make sure that the returned sample pointers as well as the types they wrap never outlive the lifetime of the subscriber. Constrain the methods accordingly.

Proceedings from the API workshop

757d893

* Introduce service discovery on consumer side * Introduce subscribe/unsubscribe * Introduce offer/unoffer on producer side * Revise receive calls on subscription side

Remove trait workaround

f4fdb47

Update UML diagrams

19f9643

ServiceDiscovery directly returns ConsumerBuilder

c6dd27b

Instead of having to create a builder from a descriptor, make the descriptor trait a supertrait of the ConsumerBuilder, and make ServiceDiscovery return a list of builders immediately.

Rename some APIs and variables

53486de

* create_provided_service -> producer_builder * find_instance -> find_service * available_services -> available_service_instances

Merge pull request eclipse-score#8 from darkwisebear/main_api_rs_draft

215dcce

Merge Rust API draft into incubator

Take SampleContainer as &mut for event receive

9d23e24

This feels more natural and makes the API less awkward to use.

Apply clippy and rustfmt

994dfe7

Clippy revealed that tere still was a lifetime issue in the allocate function. While this API is anyway still unfinished, it's good to already fix that so that we already see this during API development.

Merge pull request eclipse-score#9 from darkwisebear/main_api_rs_draft

22ae299

Add test for async consumer use case

piotrchodorowski force-pushed the pich_multi_ipc_structure branch from 281e273 to 9ceed56 Compare September 7, 2025 19:58

piotrchodorowski requested review from awillenbuecher-xq-tec, pawelrutkaq and vinodreddy-g September 8, 2025 08:21

pawelrutkaq requested changes Sep 8, 2025

View reviewed changes

awillenbuecher-xq-tec requested changes Sep 8, 2025

View reviewed changes

piotrchodorowski requested review from awillenbuecher-xq-tec and pawelrutkaq September 8, 2025 13:48

pawelrutkaq approved these changes Sep 8, 2025

View reviewed changes

piotrchodorowski force-pushed the pich_multi_ipc_structure branch 6 times, most recently from 9e87056 to 2ca4802 Compare September 9, 2025 11:20

awillenbuecher-xq-tec requested changes Sep 9, 2025

View reviewed changes

com-api/examples/com-api-gen/com-api-gen-iceoryx/Cargo.toml Outdated Show resolved Hide resolved

com-api/examples/com-api-gen/com-api-gen-lola/Cargo.toml Outdated Show resolved Hide resolved

piotrchodorowski force-pushed the pich_multi_ipc_structure branch 4 times, most recently from d7693f5 to 5760dcf Compare September 12, 2025 06:37

piotrchodorowski added 2 commits September 12, 2025 09:09

Basic structure created

f1c768c

Mock adapter interface

ad4ad39

piotrchodorowski force-pushed the pich_multi_ipc_structure branch from 5760dcf to ad4ad39 Compare September 12, 2025 07:09

piotrchodorowski added 2 commits September 24, 2025 09:03

Review fix

fe47220

Refactor runtime build

8aa12c8

Basic multi IPC adapter project structure #3

Are you sure you want to change the base?

Basic multi IPC adapter project structure #3

Uh oh!

Conversation

piotrchodorowski commented Sep 7, 2025

Uh oh!

pawelrutkaq left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

pawelrutkaq left a comment

Choose a reason for hiding this comment

Uh oh!

pawelrutkaq commented Sep 8, 2025

Uh oh!

awillenbuecher-xq-tec left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants