From 0db9ef090f274775da7f953d8fbea3ab706434e1 Mon Sep 17 00:00:00 2001 From: Michael Poehnl Date: Thu, 15 Apr 2021 13:15:57 +0200 Subject: [PATCH 1/3] iox-#482 three pillars for website Signed-off-by: Michael Poehnl --- .../getting-started/what-is-iceoryx.md | 23 +++++++++++++++++++ doc/website/index.md | 8 +++---- 2 files changed, 27 insertions(+), 4 deletions(-) diff --git a/doc/website/getting-started/what-is-iceoryx.md b/doc/website/getting-started/what-is-iceoryx.md index 494fb89eb2..2c82f0f664 100644 --- a/doc/website/getting-started/what-is-iceoryx.md +++ b/doc/website/getting-started/what-is-iceoryx.md @@ -1 +1,24 @@ # What is Eclipse iceoryx? +The technology behind Eclipse iceoryx originated in the automotive domain. With the introduction of video-based driver assistance, the amount of data to be exchanged between different threads of execution increased to GBytes/sec. The resources on these embedded systems were constrained and a solution was needed to use precious runtime for functional computations, not for shifting around bytes in memory. + +The simple answer was that we have to avoid copying of messages inside the middleware that manages the data communication between the different SW nodes. This can be done by using shared memory that can be accessed by the producers and consumers of messages. On its own, this is not a new innovation as the approach has been used since the 1970s. However, iceoryx takes the approach further, ending up in an inter-process-communication technology with a publish/subscribe architecture that is fast, flexible and dependable. + + +## Fast +With the iceoryx API, a publisher can write the message directly into a chunk of memory that was previously requested from the middleware. When the message is delivered, subscribers receive reference counted pointers to these memory chunks, which are stored in queues with configurable capacities. With this we achieve what we refer to as true zero-copy — an end-to-end approach from publishers to subscribers without creating a single copy. + +Avoiding the copies on API level is crucial when GBytes of sensor data have to be processed per second on robotics and autonomous driving systems. Therefore the iceoryx team contributed to the standardization of true zero-copy capable APIs in [ROS 2](https://www.ros.org/) and [AUTOSAR Adaptive](https://www.autosar.org/standards/adaptive-platform/). + +On modern processors iceoryx has a latency of less than 1 µs for transferring a message. And the best message is that this latency is constant as size doesn't matter. Want to give it a try? Then have a look at our [iceperf example](../examples/iceperf) after having made the first steps. +## Flexible +iceoryx already supports Linux, QNX and MacOS as operating systems as well as C and C++ as user APIs. Windows and Rust are the next ones on the list. The typed C++ API is the most comfortable when you want to go for the iceoryx API on the user side. The untyped C++ API and the C API provide a data agnostic interface that is often preferred when integrating iceoryx as shared memory backbone into a bigger framework. + +The APIs support polling access and event-driven interactions with the [Waitset](../overview/#waitset) and [Listener](../overview/#listener). Applications can be started and stopped flexibly as there is a service discovery behind the scenes that dynamically connects matching communication entities. + +That iceoryx has the right set of features can be seen from the already existing integrations in middleware and frameworks such as [Eclipse Cyclone DDS](https://github.com/eclipse-cyclonedds/cyclonedds), [eCAL from Continental](https://continental.github.io/ecal/), [RTA-VRTE from ETAS](https://www.etas.com/en/products/rta-vrte.php) and [Apex.OS from Apex.AI](https://www.apex.ai/apex-os). +## Dependable +The predecessors of iceoryx are running in millions of vehicles worldwide. We know the requirements coming from the safety critical automotive domain and have these in mind for the features we design and implement. We avoid the usage of heap, exceptions and any undefined behavior to increase the predictability. Instead we are using our own memory allocation based on static memory pools and we were inspired by upcoming C++ features and other languages like Rust for how to deal with return values and error cases (details can be found [here](../../advanced/how-optional-and-error-values-are-returned-in-iceoryx/)). + +As different processes are operating on shared data structures, avoiding deadlocks is becoming all the more important. We are using look-free data structures like our multi-producer multi-consumer (MPMC) queue that we could write in portable code thanks to modern C++. + +The tools available for automotive compliant SW development are always one or two releases behind the latest C++ standard. This fact, combined with our already mentioned constraints, led to a bunch of STL like C++ classes that have to goal to combine modern C++ with the reliability we need for the domains iceoryx is used in. They can be found in the iceoryx utils which are introduced [here](../../advanced/iceoryx_utils/) diff --git a/doc/website/index.md b/doc/website/index.md index a7bdaec1a0..7c22e0c7fe 100644 --- a/doc/website/index.md +++ b/doc/website/index.md @@ -8,9 +8,9 @@ title: Home width="50%">

-Eclipse iceoryx™ is a true zero-copy inter-process communication that allows virtually limitless data transfer at constant time. +Eclipse iceoryx™ is an inter-process-communication midddleware that enables virtually limitless data transmissions at constant time. -|

:octicons-stopwatch-16: Easy

|

:material-shield-half-full: Safe

|

:material-truck-fast: Fast

| +|

:material-truck-fast: Fast

|

::material-puzzle: Flexible

|

:material-shield-half-full: Dependable

| |----|----|-----| -|||| -|[Learn more](getting-started/what-is-iceoryx.md#easy){ .md-button }|[Learn more ](getting-started/what-is-iceoryx.md#safe){ .md-button }|[Learn more](getting-started/what-is-iceoryx.md#fast){ .md-button }| +|||| +|[Learn more](getting-started/what-is-iceoryx.md#fast){ .md-button }|[Learn more ](getting-started/what-is-iceoryx.md#flexible){ .md-button }|[Learn more](getting-started/what-is-iceoryx.md#dependable){ .md-button }| From bca13fd55d45d1dcc5825bb71f6e524e61b1b94d Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Dietrich=20Kr=C3=B6nke?= Date: Thu, 15 Apr 2021 13:49:21 +0200 Subject: [PATCH 2/3] iox-#482 set version number to 1.0.0 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Signed-off-by: Dietrich Krönke --- CHANGELOG.md | 2 +- VERSION | 2 +- cmake/package/package.cmake | 2 +- doc/aspice_swe3_4/CMakeLists.txt | 2 +- iceoryx_binding_c/CMakeLists.txt | 2 +- iceoryx_binding_c/package.xml | 2 +- iceoryx_dds/CMakeLists.txt | 2 +- iceoryx_integrationtest/package.xml | 2 +- iceoryx_posh/CMakeLists.txt | 2 +- iceoryx_posh/package.xml | 2 +- iceoryx_utils/CMakeLists.txt | 2 +- iceoryx_utils/package.xml | 2 +- tools/introspection/CMakeLists.txt | 2 +- 13 files changed, 13 insertions(+), 13 deletions(-) diff --git a/CHANGELOG.md b/CHANGELOG.md index 37d4f0a88c..52ca79ab85 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -2,7 +2,7 @@ ## [v1.0.0](https://github.com/eclipse-iceoryx/iceoryx/tree/v1.0.0) (2021-04-30) -[Full Changelog](https://github.com/eclipse-iceoryx/iceoryx/compare/v0.90.0...v1.0.0) +[Full Changelog](https://github.com/eclipse-iceoryx/iceoryx/compare/v0.90.7...v1.0.0) Description: This is the first major release for Eclipse iceoryx. That means it is the first release with long-term support and the adopters of iceoryx can rely on a stable API. The release called Almond allows for true zero-copy inter-process-communication on Linux, QNX and MacOS and provides C and modern C++ user APIs. This release is supported until 2022-04-01. diff --git a/VERSION b/VERSION index 03552ce4ff..3eefcb9dd5 100644 --- a/VERSION +++ b/VERSION @@ -1 +1 @@ -0.99.7 +1.0.0 diff --git a/cmake/package/package.cmake b/cmake/package/package.cmake index df84b842f6..f23e61f17c 100644 --- a/cmake/package/package.cmake +++ b/cmake/package/package.cmake @@ -14,7 +14,7 @@ # # SPDX-License-Identifier: Apache-2.0 cmake_minimum_required(VERSION 3.5) -set(IOX_VERSION_STRING "0.99.7") +set(IOX_VERSION_STRING "1.0.0") project(iceoryx_package VERSION ${IOX_VERSION_STRING}) diff --git a/doc/aspice_swe3_4/CMakeLists.txt b/doc/aspice_swe3_4/CMakeLists.txt index c629d9dee3..6b4c8969fa 100644 --- a/doc/aspice_swe3_4/CMakeLists.txt +++ b/doc/aspice_swe3_4/CMakeLists.txt @@ -16,7 +16,7 @@ cmake_minimum_required(VERSION 3.10) -set(IOX_VERSION_STRING "0.99.7") +set(IOX_VERSION_STRING "1.0.0") #find_package(iceoryx_utils REQUIRED) diff --git a/iceoryx_binding_c/CMakeLists.txt b/iceoryx_binding_c/CMakeLists.txt index 18001e88e5..09d2ea4ad0 100644 --- a/iceoryx_binding_c/CMakeLists.txt +++ b/iceoryx_binding_c/CMakeLists.txt @@ -16,7 +16,7 @@ # SPDX-License-Identifier: Apache-2.0 cmake_minimum_required(VERSION 3.7) -set(IOX_VERSION_STRING "0.99.7") +set(IOX_VERSION_STRING "1.0.0") diff --git a/iceoryx_binding_c/package.xml b/iceoryx_binding_c/package.xml index e1cea679e0..d0356f0e4d 100644 --- a/iceoryx_binding_c/package.xml +++ b/iceoryx_binding_c/package.xml @@ -2,7 +2,7 @@ iceoryx_binding_c - 0.99.7 + 1.0.0 Eclipse iceoryx inter-process-communication (IPC) middleware C-Language Binding Eclipse Foundation, Inc. Apache 2.0 diff --git a/iceoryx_dds/CMakeLists.txt b/iceoryx_dds/CMakeLists.txt index f3a5f72b9d..fe227ea754 100644 --- a/iceoryx_dds/CMakeLists.txt +++ b/iceoryx_dds/CMakeLists.txt @@ -16,7 +16,7 @@ # SPDX-License-Identifier: Apache-2.0 cmake_minimum_required(VERSION 3.7) -set(IOX_VERSION_STRING "0.99.7") +set(IOX_VERSION_STRING "1.0.0") project(iceoryx_dds VERSION ${IOX_VERSION_STRING}) diff --git a/iceoryx_integrationtest/package.xml b/iceoryx_integrationtest/package.xml index 1c7a69d480..bea3424ced 100644 --- a/iceoryx_integrationtest/package.xml +++ b/iceoryx_integrationtest/package.xml @@ -2,7 +2,7 @@ iceoryx_integrationtest - 0.99.7 + 1.0.0 iceoryx Software Integrationtest Eclipse Foundation, Inc. Apache 2.0 diff --git a/iceoryx_posh/CMakeLists.txt b/iceoryx_posh/CMakeLists.txt index a1419e2ea5..1284ed2c83 100644 --- a/iceoryx_posh/CMakeLists.txt +++ b/iceoryx_posh/CMakeLists.txt @@ -16,7 +16,7 @@ # SPDX-License-Identifier: Apache-2.0 cmake_minimum_required(VERSION 3.5) -set(IOX_VERSION_STRING "0.99.7") +set(IOX_VERSION_STRING "1.0.0") project(iceoryx_posh VERSION ${IOX_VERSION_STRING}) diff --git a/iceoryx_posh/package.xml b/iceoryx_posh/package.xml index 7638e1f9ba..58b69972aa 100644 --- a/iceoryx_posh/package.xml +++ b/iceoryx_posh/package.xml @@ -2,7 +2,7 @@ iceoryx_posh - 0.99.7 + 1.0.0 Eclipse iceoryx inter-process-communication (IPC) middleware Posix Shared Memory Library and middleware daemon (RouDi) Eclipse Foundation, Inc. Apache 2.0 diff --git a/iceoryx_utils/CMakeLists.txt b/iceoryx_utils/CMakeLists.txt index d8b56dd691..8496a01873 100644 --- a/iceoryx_utils/CMakeLists.txt +++ b/iceoryx_utils/CMakeLists.txt @@ -17,7 +17,7 @@ cmake_minimum_required(VERSION 3.5) -set(IOX_VERSION_STRING "0.99.7") +set(IOX_VERSION_STRING "1.0.0") #include("${CMAKE_CURRENT_LIST_DIR}/cmake/IceoryxVersion.cmake") diff --git a/iceoryx_utils/package.xml b/iceoryx_utils/package.xml index 0c0b6f1f76..636ec80bb8 100644 --- a/iceoryx_utils/package.xml +++ b/iceoryx_utils/package.xml @@ -2,7 +2,7 @@ iceoryx_utils - 0.99.7 + 1.0.0 Eclipse iceoryx inter-process-communication (IPC) middleware basic building blocks Eclipse Foundation, Inc. Apache 2.0 diff --git a/tools/introspection/CMakeLists.txt b/tools/introspection/CMakeLists.txt index 178a64949e..5f32cba915 100644 --- a/tools/introspection/CMakeLists.txt +++ b/tools/introspection/CMakeLists.txt @@ -17,7 +17,7 @@ cmake_minimum_required(VERSION 3.5) -set(IOX_VERSION_STRING "0.99.7") +set(IOX_VERSION_STRING "1.0.0") project(iceoryx_introspection VERSION ${IOX_VERSION_STRING}) From c46c6201d3d430fc4476ef1aa922549cc2dbb9bf Mon Sep 17 00:00:00 2001 From: Michael Poehnl Date: Thu, 15 Apr 2021 19:51:01 +0200 Subject: [PATCH 3/3] iox-#482 review findings Signed-off-by: Michael Poehnl --- CHANGELOG.md | 2 +- .../getting-started/what-is-iceoryx.md | 62 +++++++++++++++---- 2 files changed, 52 insertions(+), 12 deletions(-) diff --git a/CHANGELOG.md b/CHANGELOG.md index 37d4f0a88c..f2e0dbaa19 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -1,6 +1,6 @@ # Change Log -## [v1.0.0](https://github.com/eclipse-iceoryx/iceoryx/tree/v1.0.0) (2021-04-30) +## [v1.0.0](https://github.com/eclipse-iceoryx/iceoryx/tree/v1.0.0) (2021-04-15) [Full Changelog](https://github.com/eclipse-iceoryx/iceoryx/compare/v0.90.0...v1.0.0) diff --git a/doc/website/getting-started/what-is-iceoryx.md b/doc/website/getting-started/what-is-iceoryx.md index 2c82f0f664..c322f0013b 100644 --- a/doc/website/getting-started/what-is-iceoryx.md +++ b/doc/website/getting-started/what-is-iceoryx.md @@ -1,24 +1,64 @@ # What is Eclipse iceoryx? -The technology behind Eclipse iceoryx originated in the automotive domain. With the introduction of video-based driver assistance, the amount of data to be exchanged between different threads of execution increased to GBytes/sec. The resources on these embedded systems were constrained and a solution was needed to use precious runtime for functional computations, not for shifting around bytes in memory. -The simple answer was that we have to avoid copying of messages inside the middleware that manages the data communication between the different SW nodes. This can be done by using shared memory that can be accessed by the producers and consumers of messages. On its own, this is not a new innovation as the approach has been used since the 1970s. However, iceoryx takes the approach further, ending up in an inter-process-communication technology with a publish/subscribe architecture that is fast, flexible and dependable. +The technology behind Eclipse iceoryx originated in the automotive domain. With the introduction of video-based driver +assistance, the amount of data to be exchanged between different threads of execution increased to GBytes/sec. The +resources on these embedded systems were constrained and a solution was needed to use precious runtime for functional +computations, not for shifting around bytes in memory. + +The simple answer was to avoid copying of messages inside the middleware that manages the data communication between +the different software nodes. This can be done by using shared memory that can be accessed by the producers and +consumers of messages. On its own, this is not a new innovation as the approach has been used since the 1970s. +However, iceoryx takes the approach further, ending up in an inter-process-communication technology with a +publish/subscribe architecture that is fast, flexible and dependable. ## Fast -With the iceoryx API, a publisher can write the message directly into a chunk of memory that was previously requested from the middleware. When the message is delivered, subscribers receive reference counted pointers to these memory chunks, which are stored in queues with configurable capacities. With this we achieve what we refer to as true zero-copy — an end-to-end approach from publishers to subscribers without creating a single copy. -Avoiding the copies on API level is crucial when GBytes of sensor data have to be processed per second on robotics and autonomous driving systems. Therefore the iceoryx team contributed to the standardization of true zero-copy capable APIs in [ROS 2](https://www.ros.org/) and [AUTOSAR Adaptive](https://www.autosar.org/standards/adaptive-platform/). +With the iceoryx API, a publisher can write the message directly into a chunk of memory that was previously requested +from the middleware. When the message is delivered, subscribers receive reference counted pointers to these memory +chunks, which are stored in queues with configurable capacities. With this iceoryx achieves what we refer to as true +zero-copy — an end-to-end approach from publishers to subscribers without creating a single copy. + +Avoiding the copies on API level is crucial when GBytes of sensor data have to be processed per second on robotics and +autonomous driving systems. Therefore the iceoryx team contributed to the standardization of true zero-copy capable +APIs in [ROS 2](https://www.ros.org/) and [AUTOSAR Adaptive](https://www.autosar.org/standards/adaptive-platform/). -On modern processors iceoryx has a latency of less than 1 µs for transferring a message. And the best message is that this latency is constant as size doesn't matter. Want to give it a try? Then have a look at our [iceperf example](../examples/iceperf) after having made the first steps. +On modern processors iceoryx has a latency of less than 1 µs for transferring a message. And the best message is that +this latency is constant as size doesn't matter. Want to give it a try? Then have a look at our +[iceperf example](../examples/iceperf) after having made the first steps. + ## Flexible -iceoryx already supports Linux, QNX and MacOS as operating systems as well as C and C++ as user APIs. Windows and Rust are the next ones on the list. The typed C++ API is the most comfortable when you want to go for the iceoryx API on the user side. The untyped C++ API and the C API provide a data agnostic interface that is often preferred when integrating iceoryx as shared memory backbone into a bigger framework. -The APIs support polling access and event-driven interactions with the [Waitset](../overview/#waitset) and [Listener](../overview/#listener). Applications can be started and stopped flexibly as there is a service discovery behind the scenes that dynamically connects matching communication entities. +iceoryx already supports Linux, QNX and MacOS as operating systems as well as C and C++ as user APIs. Windows and Rust +are the next ones on the list. The typed C++ API is the most comfortable when you want to directly use the iceoryx API +on the user side. The untyped C++ API and the C API provide a data agnostic interface that is often preferred when +integrating iceoryx as shared memory backbone into a bigger framework. + +The APIs support polling access and event-driven interactions with the [Waitset](../overview/#waitset) and +[Listener](../overview/#listener). Applications can be started and stopped flexibly as there is a service discovery +behind the scenes that dynamically connects matching communication entities. + +That iceoryx has the right set of features can be seen from the already existing integrations in middleware and +frameworks such as [Eclipse Cyclone DDS](https://github.com/eclipse-cyclonedds/cyclonedds), + [eCAL from Continental](https://continental.github.io/ecal/), + [RTA-VRTE from ETAS](https://www.etas.com/en/products/rta-vrte.php) and + [Apex.OS from Apex.AI](https://www.apex.ai/apex-os). -That iceoryx has the right set of features can be seen from the already existing integrations in middleware and frameworks such as [Eclipse Cyclone DDS](https://github.com/eclipse-cyclonedds/cyclonedds), [eCAL from Continental](https://continental.github.io/ecal/), [RTA-VRTE from ETAS](https://www.etas.com/en/products/rta-vrte.php) and [Apex.OS from Apex.AI](https://www.apex.ai/apex-os). ## Dependable -The predecessors of iceoryx are running in millions of vehicles worldwide. We know the requirements coming from the safety critical automotive domain and have these in mind for the features we design and implement. We avoid the usage of heap, exceptions and any undefined behavior to increase the predictability. Instead we are using our own memory allocation based on static memory pools and we were inspired by upcoming C++ features and other languages like Rust for how to deal with return values and error cases (details can be found [here](../../advanced/how-optional-and-error-values-are-returned-in-iceoryx/)). -As different processes are operating on shared data structures, avoiding deadlocks is becoming all the more important. We are using look-free data structures like our multi-producer multi-consumer (MPMC) queue that we could write in portable code thanks to modern C++. +The predecessor of iceoryx is running in millions of vehicles worldwide. All iceoryx maintainers hail from the +safety critical automotive domain. Hence, they know the necessary requirements and have these in mind for the +design and implementation of features. The usage of heap, exceptions and any undefined behavior are to be avoided +to increase the predictability. Instead a custom memory allocation is being used, based on static memory pools. +Additionally, the handling of return values and error cases was inspired by upcoming C++ features and other +languages like Rust (details can be found +[here](../../advanced/how-optional-and-error-values-are-returned-in-iceoryx/)). + +As different processes are operating on shared data structures, avoiding deadlocks is becoming all the more important. +iceoryx uses look-free data structures like the multi-producer multi-consumer (MPMC) queue that was written portably +thanks to modern C++. -The tools available for automotive compliant SW development are always one or two releases behind the latest C++ standard. This fact, combined with our already mentioned constraints, led to a bunch of STL like C++ classes that have to goal to combine modern C++ with the reliability we need for the domains iceoryx is used in. They can be found in the iceoryx utils which are introduced [here](../../advanced/iceoryx_utils/) +The tools available for automotive-compliant software development are always one or two releases behind the latest C++ +standard. This fact, combined with our already mentioned constraints, led to a bunch of STL like C++ classes that have +the goal to combine modern C++ with the reliability needed for the domains iceoryx is used in. They can be found in +the iceoryx utils which are introduced [here](../../advanced/iceoryx_utils/)