eclipse-iceoryx / iceoryx-rs Goto Github PK

Brief feature description

For use in FFI, it would be helpful to have a raw pointer API. See also #63

Right now the only way to initialize a Runtime is through the init function. This function blocks until it establishes a connection to the RouDi daemon, or terminates the whole process on a timeout. This is not desired for robust applications, so it would be good to also have a try_init(app_name) -> Result function that just returns an error in this case. Ideally, the wait timeout would also be configurable.

Brief feature description

The current API was crafted before the iceoryx v1 release and does not fit the changes introduced with v1 and v2 quite well.

Additionally, there are some new publisher and subscriber options which should also be supported by the Rust binding.

Detailed information

• Adjust the publisher and subscriber options to match iceoryx v2
• Replace the pb::Topic and pb::TopicBuilder structs with InactivePublisher and PublisherBuilder with the option to create publisher to offer on create
• Replace the sb::Topic and sb::TopicBuilder structs with InactiveSubscriber and SubscriberBuilder with the option to create subscriber to subscribe on create
• Align the naming to the iceoryx C++ API as much as possible, e.g. use loan instead of allocate_sample

Brief feature description

Create an untyped API that works on [u8] slices.

Detailed information

Add allocates method to the publisher impl like

pub fn allocate(length: usize) -> SampleMut<[u8]> {}

pub fn allocate_aligned(length: usize, alignment: usize) -> SampleMut<[u8]> {}

The subscriber shall also be able to work with slices.

This should enable us to expose &mut [u8] and have a nice compatibility with the bytes::BufMut trait from the bytes crate

Brief feature description

cargo nextest has some nice features compared to cargo test

• nicer output
• faster test execution
• can re-run failed tests and mark them as flaky
• tests can be partitioned in the CI and distributed to multiple runners to speedup test execution

Limitations

doctests are currently not supported -> run cargo test --doc

Considerations

The tests must not be run in parallel and therefore either -j 1 or --test-threads 1 options must be used.
Since this is easy to forget, test-threads = 1 option should be added to .config/nextest.toml

Document the public API with rustdoc

PR should only be merged when the tests pass

This is should most probably done after #5

Currently iceoryx is a submodule in iceoryx-rs. It would be better to let build.rs clone the repo before building it. This would prevent issues when user clone iceoryx-rs without the --recursive flag

Brief feature description

In order to notice when publishing to crates.io is broken a CI job to run cargo publish --dry-run should be created

would be nice if you guys could publish a new release crate with a version bump. i tried running the examples in the dir and they don't compile on 0.1.0, i had to check out the version from latest master branch. thanks

Brief feature description

The CI config to build cargo-nextest and grcov is copy&pasted. To reduce duplication, this should be refactored out to a custom action.

Bundle iceoryx C++ sources instead of fetching them via git. This will fix the documentation on docs.rs.

From https://kornel.ski/rust-sys-crate#donts

Avoid downloading anything. There are packaging and deployment tools that require builds
to run off-line in isolated containers. If you want to build the library from source,
bundle the source in the Cargo crate.

Cargo build process is supposed to be entirely self-contained and work off-line.

Brief feature description

With cargo nextes it is possible to distribute the execution of tests to multiple runners. This will speed up the CI.

Detailed information

When the number of tests increase, this will have a significant impact on the CI since most of the tests use the RouDiEnvironment which results in ~300ms minimal execution time. Therefore the tests should be distributed to two runners as a starting point.

A CI profile could be used to also add repetition for failed tests.

Add git hooks for

• cargo fmt
• commit message with issue number

Brief feature description

In order to have a machine readable copyright and contributor notice in the files, SPDX-FileCopyrightText and SPDX-FileContributor shall be used

Brief feature description

Our service uses iox-roudi when communicating with cyclonedds shm.

Since cyclonedds depends on the iox-roudi service, we have to start the iox-roudi service before running our own C++ service.

Is there any sdk way to integrate iox-roudi in our C++ system?

Required information

Operating system:
E.g. Ubuntu 20.04 LTS

Rust version:
E.g. Rust 1.55.0

Observed result or behaviour:
A clear and precise description of the observed result.

Expected result or behaviour:
What do you expect to happen?

Conditions where it occurred / Performed steps:
Describe how one can reproduce the bug.

`root@MSI:~/2.iceoryx-rs/iceoryx-rs# cargo build
Compiling iceoryx-rs v0.0.10 (/root/2.iceoryx-rs/iceoryx-rs)
The following warnings were emitted during compilation:

warning: src/runtime.rs:8:14: fatal error: iceoryx_posh/runtime/posh_runtime.hpp: No such file or directory
warning: 8 | #include "iceoryx_posh/runtime/posh_runtime.hpp"
warning: | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
warning: compilation terminated.

error: failed to run custom build command for iceoryx-rs v0.0.10 (/root/2.iceoryx-rs/iceoryx-rs)

Caused by:
process didn't exit successfully: /root/2.iceoryx-rs/iceoryx-rs/target/debug/build/iceoryx-rs-3895b6884be6cb5f/build-script-build (exit status: 1)
--- stdout
Output { status: ExitStatus(unix_wait_status(0)), stdout: "", stderr: "HEAD is now at ebdfcc5df Merge pull request #1312 from ApexAI/iox-#1311-increase-version-to-2.0.1\n" }
Output { status: ExitStatus(unix_wait_status(0)), stdout: "", stderr: "" }
Output { status: ExitStatus(unix_wait_status(0)), stdout: "-- Configuring done\n-- Generating done\n-- Build files have been written to: /root/2.iceoryx-rs/iceoryx-rs/target/iceoryx-build/iceoryx_hoofs\n", stderr: "" }
Output { status: ExitStatus(unix_wait_status(512)), stdout: "[ 17%] Built target iceoryx_platform\n[ 20%] Building CXX object CMakeFiles/iceoryx_hoofs.dir/source/posix_wrapper/access_control.cpp.o\n", stderr: "In file included from /root/2.iceoryx-rs/iceoryx-rs/target/iceoryx-git/iceoryx_hoofs/include/iceoryx_hoofs/internal/posix_wrapper/access_control.hpp:23,\n from /root/2.iceoryx-rs/iceoryx-rs/target/iceoryx-git/iceoryx_hoofs/source/posix_wrapper/access_control.cpp:18:\n/root/2.iceoryx-rs/iceoryx-rs/target/iceoryx-git/iceoryx_hoofs/platform/linux/include/iceoryx_hoofs/platform/acl.hpp:20:10: fatal error: sys/acl.h: No such file or directory\n 20 | #include <sys/acl.h>\n | ^~~~~~~~~~~\ncompilation terminated.\nmake[2]: *** [CMakeFiles/iceoryx_hoofs.dir/build.make:271: CMakeFiles/iceoryx_hoofs.dir/source/posix_wrapper/access_control.cpp.o] Error 1\nmake[1]: *** [CMakeFiles/Makefile2:96: CMakeFiles/iceoryx_hoofs.dir/all] Error 2\nmake: *** [Makefile:130: all] Error 2\n" }
Output { status: ExitStatus(unix_wait_status(0)), stdout: "", stderr: "" }
Output { status: ExitStatus(unix_wait_status(256)), stdout: "-- Configuring incomplete, errors occurred!\nSee also "/root/2.iceoryx-rs/iceoryx-rs/target/iceoryx-build/iceoryx_posh/CMakeFiles/CMakeOutput.log".\nSee also "/root/2.iceoryx-rs/iceoryx-rs/target/iceoryx-build/iceoryx_posh/CMakeFiles/CMakeError.log".\n", stderr: "CMake Error at CMakeLists.txt:24 (find_package):\n By not providing "Findiceoryx_hoofs.cmake" in CMAKE_MODULE_PATH this\n project has asked CMake to find a package configuration file provided by\n "iceoryx_hoofs", but CMake did not find one.\n\n Could not find a package configuration file provided by "iceoryx_hoofs"\n with any of the following names:\n\n iceoryx_hoofsConfig.cmake\n iceoryx_hoofs-config.cmake\n\n Add the installation prefix of "iceoryx_hoofs" to CMAKE_PREFIX_PATH or set\n "iceoryx_hoofs_DIR" to a directory containing one of the above files. If\n "iceoryx_hoofs" provides a separate development package or SDK, be sure it\n has been installed.\n\n\n" }
Output { status: ExitStatus(unix_wait_status(512)), stdout: "", stderr: "make: *** No rule to make target 'install'. Stop.\n" }
TARGET = Some("x86_64-unknown-linux-gnu")
OPT_LEVEL = Some("0")
HOST = Some("x86_64-unknown-linux-gnu")
CXX_x86_64-unknown-linux-gnu = None
CXX_x86_64_unknown_linux_gnu = None
HOST_CXX = None
CXX = None
CXXFLAGS_x86_64-unknown-linux-gnu = None
CXXFLAGS_x86_64_unknown_linux_gnu = None
HOST_CXXFLAGS = None
CXXFLAGS = None
CRATE_CC_NO_DEFAULTS = None
DEBUG = Some("true")
CARGO_CFG_TARGET_FEATURE = Some("fxsr,sse,sse2")
running: "c++" "-O0" "-ffunction-sections" "-fdata-sections" "-fPIC" "-g" "-fno-omit-frame-pointer" "-m64" "-I" "/root/2.iceoryx-rs/iceoryx-rs" "-I" "/root/2.iceoryx-rs/iceoryx-rs/target/iceoryx-install/include/iceoryx/v2.0.1" "-Wall" "-Wextra" "-Wno-noexcept-type" "-std=c++14" "-o" "/root/2.iceoryx-rs/iceoryx-rs/target/debug/build/iceoryx-rs-e6a6ce3817c727f2/out/rust_cpp/cpp_closures.o" "-c" "/root/2.iceoryx-rs/iceoryx-rs/target/debug/build/iceoryx-rs-e6a6ce3817c727f2/out/rust_cpp/cpp_closures.cpp"
cargo:warning=src/runtime.rs:8:14: fatal error: iceoryx_posh/runtime/posh_runtime.hpp: No such file or directory
cargo:warning= 8 | #include "iceoryx_posh/runtime/posh_runtime.hpp"
cargo:warning= | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
cargo:warning=compilation terminated.
exit status: 1

--- stderr

error occurred: ToolExecError: Command "c++" "-O0" "-ffunction-sections" "-fdata-sections" "-fPIC" "-g" "-fno-omit-frame-pointer" "-m64" "-I" "/root/2.iceoryx-rs/iceoryx-rs" "-I" "/root/2.iceoryx-rs/iceoryx-rs/target/iceoryx-install/include/iceoryx/v2.0.1" "-Wall" "-Wextra" "-Wno-noexcept-type" "-std=c++14" "-o" "/root/2.iceoryx-rs/iceoryx-rs/target/debug/build/iceoryx-rs-e6a6ce3817c727f2/out/rust_cpp/cpp_closures.o" "-c" "/root/2.iceoryx-rs/iceoryx-rs/target/debug/build/iceoryx-rs-e6a6ce3817c727f2/out/rust_cpp/cpp_closures.cpp" with args "c++" did not execute successfully (status code exit status: 1).`

Brief feature description

Update links which use the old master default branch and also some author information

Brief feature description

Yeah, the iceoryx logo is awesome but what about combining the rust logo with the iceoryx logo so that the gear surrounds iceoryx.

See this here: https://raw.githubusercontent.com/CodeSandwich/mocktopus/master/logo.png
Oh look, here is the rust gear: https://aws1.discourse-cdn.com/business5/uploads/rust_lang/original/2X/b/b76205bdf28142dc668eba92401f979de1f9eb16.png

I think rust also needs at least an 8k logo.

Required information

According to: https://doc.rust-lang.org/nomicon/repr-rust.html

There is no indirection for these types; all data is stored within the struct, as you would expect in C. 
However with the exception of arrays (which are densely packed and in-order), the layout of data is 
not specified by default.

Translated it means, when I have a struct:

struct A {
    a: u8,
    b: u32,
    c: u16,
}

The memory representation can look like:

struct A { // version 1 
    a: u8,
    _pad1: [u8; 3], // to align `b`
    b: u32,
    c: u16,
    _pad2: [u8; 2], // to make overall size multiple of 4
}

or for instance like this:

struct A { // version 2
    b: u32,
    c: u16,
    a: u8,
    _pad: u8,
}

Therefore, we require #[repr(C)] for interoperability with C - which is already done in the Counter type in the example.

But I think this is also a hard requirement for communication between rust only apps. Otherwise it is possible that one app uses version 1 of A and the other one is using version 2?!

Could a possible solution to this problem be a custom trait (which already exists under the name ShmSend) in combination with a custom derive?
This also could be a very ugly problem for the untyped rust api when one acquires memory and writes the custom type later in it.

It seems actions-rs are unmaintained. Fortunately there is a solution from dtolnay so we should switch to dtolnay/rust-toolchain@v1

Required information

It seems the introduction of workspaces broke codecov. Most probably this could be fixed by generating and uploading coverage results for each workspace separately, e.g. for iceoryx-rs and iceoryx-rs[sys]

To fully integrate into the Rust ecosystem iceoryx-rs should be available via crates.io.

At least #1 and #4 should be finished before the release.

Brief feature description

iceoryx builtin types like iox::cxx::string and iox::cxx::vector should be supported

Detailed information

The idea is to have something similar to this https://docs.rs/cxx/latest/cxx/#builtin-types

So there would be a CxxString, IoxString or IoxCxxString which would have the same layout as the C++ counterpart. What makes things interesting is the template argument but that should also be solvable.

We would have to be really carefully with this and need to adapt the types when the ABI of the C++ counterpart changes.

Brief feature description

iceoryx-rs is not compatible with iceoryx v2.0

Detailed information

Due to some breaking changes in iceoryx, the wrapper does not build anymore and needs adjustments

Brief feature description

The examples duplicate the struct with the data transmitted via shared memory. This is error prone when the struct is changed in one example but not in another one. The struct should be shared with all examples.

Check if this can be done by a static lib like

[[example]]
name = "shm-data"
crate-type = ["staticlib"]

Since the data of the samples is not initialized, this should be reflected by the type system with MaybeUninit. The user then either has to use assume_init before sending the sample or it might be done under the hood. Alternatively MaybeUninit<T> could be transmuted to T.

Brief feature description

Currently there are quite a lot of clippy warnings, especially in the sys crate. This needs to be fixed

Brief feature description

The iceoryx-sys crate now uses cmake to compile the library and iox-roudi but ignoring cross compilation environment variables such as TARGET and HOST.

Detailed information

Computation platform like NVidia Jetson and Rockchip RK3588 are aarch64. When we use CI/CD environment to cross compile binaries for those targets, it will fail because generates host binaries.

We need to support cross compilation on aarch64-unknown-linux-gnu targets.

Brief feature description

The POD marker trait is used to mark data types which can be transferred across process boundaries. This is similar to std::marker::Send which is used for data types which can be transferred across thread boundaries. To utilize this familiarity, POD should be renamed to ShmSend

Currently iceoryx is build together with iceoryx-rs. There might be cases where it is desired to use pre-build iceoryx libraries to guarantee binary compatibility with the static libs.

This could be done by an environment variable which can be checked in build.rs. In this case It should also be possible to use dynamic libraries.

This should be done after #7

Brief feature description

grcov creates a nice html coverage result. Currently they are archived in the CI but it would be great to publish them via github pages and add a badge with the coverage result to the readme

Currently it's not possible to wait for multiple subscriber in the same thread since there is one condition_variable used for each Subscriber. In order to wait for multiple subscriber in one thread, a similar functionality like the Listener/WaitSet from the C++ implementation is needed.

Due to the ownership semantics something similar to a stateless WaitSet might be the best solution for this problem. The user would need to start a thread by oneself, which is also more idiomatic rust than starting a thread in the background.

If this feature is needed in the short therm, the corresponding C++ classes could be wrapped.

We want to use the same formalism like in iceoryx itself

Currently there are no test. At least integration test should be created before a 0.1 release