Add read/write instrumentation with LTTng

.azure/templates/build-test.yml

@@ -15,6 +15,8 @@
 #
 
 steps:
+  - bash: bash versioncheck.bash
+    name: versioncheck
   - task: UsePythonVersion@0
     inputs:
       versionSpec: '3.8'
@@ -71,6 +73,11 @@ steps:
       path: $(pip_cache)
     name: cache_pip
   - template: /.azure/templates/install-conan.yml
+  - bash: |
+      set -e -x
+      pip install gcovr --user --upgrade
+    condition: eq(variables['coverage'], 'on')
+    name: install_gcovr
   - bash: |
       set -e -x
       if [[ "${ICEORYX}" = 'on' ]] ; then
@@ -126,3 +133,16 @@ steps:
             ${GENERATOR:+-G} "${GENERATOR}" -A "${PLATFORM}" -T "${TOOLSET}" "${INSTALLPREFIX}/share/CycloneDDS/examples/helloworld"
       cmake --build . --config ${BUILD_TYPE} -- ${BUILD_TOOL_OPTIONS}
     name: test
+  - bash: |
+      set -e -x
+      cd build
+      cmake --build . --config ${BUILD_TYPE} --target gcov -- ${BUILD_TOOL_OPTIONS}
+      gcovr --exclude '.*/tests/.*' --root "${BUILD_SOURCESDIRECTORY}" --xml-pretty --output coverage.xml .
+    condition: eq(variables['coverage'], 'on')
+    name: generate_code_coverage
+  - task: PublishCodeCoverageResults@1
+    inputs:
+      codeCoverageTool: 'Cobertura'
+      summaryFileLocation: $(Build.SourcesDirectory)/build/coverage.xml
+    condition: eq(variables['coverage'], 'on')
+    name: publish_code_coverage

CMakeLists.txt

@@ -10,7 +10,7 @@
 # SPDX-License-Identifier: EPL-2.0 OR BSD-3-Clause
 #
 cmake_minimum_required(VERSION 3.7)
-project(CycloneDDS VERSION 0.8.0 LANGUAGES C)
+project(CycloneDDS VERSION 0.8.2 LANGUAGES C)
 if(CMAKE_VERSION VERSION_LESS 3.12)
   # GENERATE_EXPORT_HEADER requires a C++ compiler up to version 3.12
   enable_language(CXX)
@@ -27,14 +27,22 @@ if(NOT CMAKE_BUILD_TYPE AND NOT CMAKE_CONFIGURATION_TYPES)
     "Debug" "Release" "MinSizeRel" "RelWithDebInfo")
 endif()
 
+if(CMAKE_CROSSCOMPILING)
+  set(not_crosscompiling OFF)
+else()
+  set(not_crosscompiling ON)
+endif()
+
 # By default don't treat warnings as errors, else anyone building it with a different compiler that
 # just happens to generate a warning, as well as anyone adding or modifying something and making a
 # small mistake would run into errors.  CI builds can be configured differently.
 option(WERROR "Treat compiler warnings as errors" OFF)
 
 set(CMAKE_MODULE_PATH "${CMAKE_CURRENT_LIST_DIR}/cmake/Modules")
 
-option(BUILD_IDLC "Build IDL preprocessor" ON)
+option(BUILD_IDLC "Build IDL preprocessor" ${not_crosscompiling})
+option(BUILD_DDSCONF "Build DDSCONF buildtool" ${not_crosscompiling})
+
 
 set(CMAKE_C_STANDARD 99)
 if(CMAKE_SYSTEM_NAME STREQUAL "VxWorks")
@@ -207,9 +215,6 @@ if(ANALYZER)
         # -Wanalyzer-malloc-leak generates lots of false positives
         add_compile_options(-fanalyzer -Wno-analyzer-malloc-leak)
       endif()
-    elseif(CMAKE_C_COMPILER_ID STREQUAL "MSVC")
-      message(STATUS "Enabling analyzer: MSVC")
-      add_compile_options(/analyze:stacksize 524288)
     endif()
   endif()
 endif()
@@ -231,22 +236,17 @@ if(SANITIZER)
 endif()
 
 find_package(codecov)
-include(Codecov)
 set(MEMORYCHECK_COMMAND_OPTIONS "--track-origins=yes --leak-check=full --trace-children=yes --child-silent-after-fork=yes --xml=yes --xml-file=TestResultValgrind_%p.xml --tool=memcheck --show-reachable=yes --leak-resolution=high")
 
 # By default building the testing tree is enabled by including CTest, but
 # since not everybody has CUnit, and because it is not strictly required to
 # build the product itself, switch to off by default.
 option(BUILD_TESTING "Build the testing tree." OFF)
+
 # Disable building examples by default because it is not strictly required.
 option(BUILD_EXAMPLES "Build examples." OFF)
 
 option(BUILD_DOCS "Build documentation." OFF)
-if(CMAKE_CROSSCOMPILING)
-  set(not_crosscompiling OFF)
-else()
-  set(not_crosscompiling ON)
-endif()
 option(BUILD_SCHEMA "Build generated schema for configuration options." ${not_crosscompiling})
 
 # Build all executables and libraries into the top-level /bin and /lib folders.
@@ -303,7 +303,7 @@ install(
   COMPONENT dev)
 
 add_subdirectory(src)
-if(BUILD_IDLC AND BUILD_EXAMPLES)
+if(BUILD_EXAMPLES)
   add_subdirectory(examples)
 endif()
 

CYCLONEDDS_QUALITY_DECLARATION.md

@@ -1,8 +1,8 @@
-This document is a declaration of software quality for the [Eclipse Cyclone DDS](https://github.com/eclipse-cyclonedds/cyclonedds) (hereafter simply "Cyclone DDS") project, based on the guidelines in [REP-2004](https://www.ros.org/reps/rep-2004.html).
+This document is a declaration of software quality for the [Eclipse Cyclone DDS](https://github.com/eclipse-cyclonedds/cyclonedds) (hereafter simply "Cyclone DDS") project, based on the guidelines in [REP-2004](https://www.ros.org/reps/rep-2004.html). This quality declaration is therefore specific to use in [ROS 2](https://index.ros.org/doc/ros2/)-based systems.
 
 # Cyclone DDS Quality Declaration
 
-Cyclone DDS meets all the requirements of **Quality Level 3** category.
+Cyclone DDS meets all the requirements of **Quality Level 2** category.
 The requirements for the various quality level categories are defined by [REP-2004](https://www.ros.org/reps/rep-2004.html).
 The rationale, notes and caveats for this claim are provided by the remainder of this document.
 
@@ -37,19 +37,21 @@ The change history can be found in the [CHANGELOG](https://github.com/eclipse-cy
 
 Symbols starting with `dds_` or `DDS_` and that are accessible after including only the top-level `dds.h` file, unless explicitly stated otherwise in a documentation comment, constitute the Public API.
 
-Definitions available in installed include files that are outside this definitions are either internal or part of an Evolving API that is expected to eventually become part of the Public API.
-The distinction between Evolving APIs and internal definitions is currently not well-defined.
+Definitions available in installed include files that are outside this definitions are either internal or part of an Evolving API that is expected to eventually become part of the Public API. Internal definitions are deliberately included in the install: the project chooses not to artifically limit users of Cyclone DDS to the Public or Evolving APIs.
 
 In the source repository, these header files reside with the modules that make up Cyclone DDS.
 
 ### API Stability Policy [1.iv]
 
-Cyclone DDS provides Public API stability for PATCH and MINOR releases.
-Cyclone DDS strives to provide Public API stability for MAJOR releases.
-Cyclone DDS does not guarantee Public API stability for MAJOR releases.
+For the Public API:
+* Cyclone DDS provides Public API stability for PATCH and MINOR releases.
+* Cyclone DDS strives to provide Public API stability for MAJOR releases.
+* Cyclone DDS does not guarantee Public API stability for MAJOR releases.
 
-Cyclone DDS provides Evolving API stability for PATCH releases and strives to provide Evolving API stability for MINOR releases.
-Cyclone DDS does not guarantee Evolving API stability for MINOR and MAJOR releases.
+For the Evolving API:
+* Cyclone DDS provides Evolving API stability for PATCH releases.
+* Cyclone DDS strives to provide Evolving API stability for MINOR releases.
+* Cyclone DDS does not guarantee Evolving API stability for MINOR and MAJOR releases.
 
 The RMW interface is what ROS 2 deals with, and for a variety of reasons it may be decided to rely on unstable interfaces (or even implementation details), to better support ROS 2's design decisions that do not fit so well with DDS.
 Given ROS 2's importance to Cyclone DDS the Public API is expected to eventually cover all of ROS 2's needs, but without a defined time-line for that to happen.
@@ -69,7 +71,7 @@ Cyclone DDS does not guarantee ABI stability for MINOR or MAJOR releases.
 
 ROS 2 users do not interact directly with Cyclone DDS and the mapping of the RMW interface to the Cyclone DDS APIs provided by the `rmw_cyclonedds` package hides any API or ABI changes from ROS 2 users.
 
-Based on the ABI Stability Policy, Cyclone DDS PATCH releases can be accepted as updates within a Released ROS Distribution without also requiring an update to the `rmw_cyclonedds` package.
+Based on the ABI Stability Policy, Cyclone DDS PATCH releases can be accepted as updates within a Released ROS Distribution. MINOR releases can likely be accepted as updates after assessing the binary compatibility.
 Cyclone DDS MINOR and MAJOR releases can, at least in principle, be accepted as updates within a Released ROS Distribution if the update is accompanied by an update of the `rmw_cyclonedds` package.
 
 ## Change Control [2]
@@ -93,20 +95,21 @@ Eclipse projects furthermore require that an [Eclipse Contributor Agreement](htt
 
 ### Peer Review Policy [2.iii]
 
-All pull requests must pass peer-review except when no-one is able to provide a review for a PR introduced by a Committer.
+All pull requests must pass peer-review except when no-one is able to provide a review for a PR introduced by a Committer. The exception exists solely as an escape hatch if no review can be obtained within a reasonable time frame while there is an urgent need for the change introduced by the PR.
 Check [Eclipse Developer Process](https://www.eclipse.org/projects/dev_process/) for additional information.
 
 ### Continuous Integration [2.iv]
 
 Pull requests are required to pass all tests in the CI system prior to merging, unless Committers consider there is sufficient evidence that a failure is the result of a mishap unrelated to the change.
-Cyclone DDS CI results are [public](https://dev.azure.com/eclipse-cyclonedds/cyclonedds/_build) and cover x64 platforms running Linux, macOS and Windows:
+Cyclone DDS CI results are [public](https://dev.azure.com/eclipse-cyclonedds/cyclonedds/_build) and cover x64 and x86 platforms running Linux, macOS and Windows:
 
 - Ubuntu 20.04 with gcc 10
-- Ubuntu 18.04 with gcc 10
 - Ubuntu 18.04 with gcc 7
 - Ubuntu 20.04 with clang 10
 - macOS 10.15 with clang 12
+- macOS 10.15 with clang 12 while targeting macOS 10.12
 - Windows Server 2019 with Visual Studio 2019
+- Windows Server 2019 with gcc 10 (mingw)
 
 These are run with a mixture of debug, debug-with-address sanitizer and release builds.
 
@@ -120,22 +123,18 @@ All pull requests must resolve related documentation changes before merging.
 
 ### Feature Documentation [3.i]
 
-The project documentation does not include a high-level overview of the features and concepts.
-These closely follow the [OMG DDS specification](https://www.omg.org/spec/DDS/1.4/PDF) which provides an accessible description.
+The project documentation includes a getting started that introduces the high-level concepts, but it generally prefers to instead refer to the [OMG DDS specification](https://www.omg.org/spec/DDS/1.4/PDF) for an accessible and full description of the concepts and high-level features.
 
-Some components can be enabled/disabled at compile-time through compilation options from the CMake files (e.g., DDS Security support).
-The exact set is not well-documented.
-Some other features are included/excluded at build time based on the features provided by the target platform (e.g., source-specific multicasting, DNS support to allow hostnames to be used in the configuration).
-These are also not well-documented.
+Some components can be enabled/disabled at compile-time through compilation options from the CMake files (e.g., DDS Security support). These are done with CMake options.
+
+Some other features are included/excluded at build time based on the features provided by the target platform (e.g., source-specific multicasting, DNS support to allow hostnames to be used in the configuration). All features are available on the tier 1 platforms, the ability to exclude them is needed for embedded platforms such as FreeRTOS.
 
 ### Public API Documentation [3.ii]
 
-Reference information for the Public API is provided in the form of Doxygen comments.
+Reference information for the Public API is provided in the form of Doxygen comments. Generated documentation is provided [online](https://cyclonedds.io).
 Configuration settings are documented in the source, with auto-generated [XSD files](https://github.com/eclipse-cyclonedds/cyclonedds/blob/master/etc/cyclonedds.xsd) and [markdown files](https://github.com/eclipse-cyclonedds/cyclonedds/blob/master/docs/manual/options.md) committed in the repository and linked from the front page.
 [Background information](https://github.com/eclipse-cyclonedds/cyclonedds/blob/master/docs/manual/config.rst) on configuration settings is also provided.
 
-Generated documentation for the API is available in the [PDF document](https://raw.githubusercontent.com/eclipse-cyclonedds/cyclonedds/assets/pdf/CycloneDDS-0.1.0.pdf) linked in the project README.
-
 ### License [3.iii]
 
 The license for Cyclone DDS is the Eclipse Public License 2.0 and the Eclipse Distribution License 1.0, and all of the code includes a header stating so.
@@ -149,27 +148,29 @@ Details can also be found in the included [`NOTICE`](https://github.com/eclipse-
 
 The Cyclone DDS documentation includes a [policy](https://github.com/eclipse-cyclonedds/cyclonedds/blob/master/NOTICE.md#copyright) regarding content copyright, each of the source files containing code include a copyright statement with the license information in the file's header.
 
+### Lists and Peer Review [3.v.c]
+
+This section is not applicable to a non-ROS project.
+
 ## Testing [4]
 
-Some directories within the Cyclone DDS source tree contain subdirectories for test code.
-In all, the test code appears to comprise approximately 25% of the codebase.
+Cyclone DDS source tree includes subdirectories for test code.
+In all, the test code comprises approximately 25% of the codebase.
 
 ### Feature Testing [4.i]
 
 Each feature in Cyclone DDS has corresponding tests which simulate typical usage, and they are located in separate directories next to the sources.
 New features are required to have tests before being added.
 
 A substantial amount of the tests found throughout the source tree verify functionality of various features of Cyclone DDS.
-However the lack of a complete feature list (see section [3.i]) makes it difficult to analyze the breadth of the tests.
 
 ### Public API Testing [4.ii]
 
 Each part of the public API has tests, and new additions or changes to the public API require tests before being added.
 The tests aim to cover both typical usage and corner cases.
 There are some tests throughout the Cyclone DDS source tree which specifically target the public API.
-In principle the entire interface does get tested, and in reality it is pretty close.
 
-Current lack of analysis of which parts of the code get hit by tests do make it hard to measure the extent of the tests.
+There is no automated tracking of correlation between tests and API functionality. On the basis of a manual assessment conducted by the project, the overall number of tests and the number of reported issues, it is fair to conclude that the Public API is well-covered.
 
 In continuous integration, address sanitizer is enabled for some of the test matrix. Address sanitizer errors result in CI failure.
 
@@ -193,12 +194,8 @@ We suggest and would like to assist Open Robotics to move all performance testin
 `rmw_cyclonedds` uses and passes all the ROS2 standard linters and static analysis tools for a C++ package as described in the [ROS 2 Developer Guide](https://index.ros.org/doc/ros2/Contributing/Developer-Guide/#linters-and-static-analysis).
 Passing implies there are no linter/static errors when testing against CI of supported platforms.
 
-Cyclone DDS has automated daily [Synopsys Coverity static code analysis](https://www.synopsys.com/software-integrity/security-testing/static-analysis-sast.html) with public results that can be seen [here](https://scan.coverity.com/projects/eclipse-cyclonedds-cyclonedds).
-Cyclone DDS defect density is 0.05 per 1,000 lines of code as of Aug 11th 2020.
-Omitting the Java idlc which is **not** used by ROS 2 gives 0.03 per 1,000 lines of code.
-For comparison the average defect density of open source software projects of similar size is 0.5 per 1,000 lines of code.
-
-There are no linters enabled for the Cyclone DDS repository.
+Cyclone DDS has automated [Synopsys Coverity static code analysis](https://www.synopsys.com/software-integrity/security-testing/static-analysis-sast.html) with public results that can be seen [here](https://scan.coverity.com/projects/eclipse-cyclonedds-cyclonedds).
+Cyclone DDS has no outstanding defects as of 20-09-2021 on 240k lines analyzed. For comparison the average defect density of open source software projects of similar size is 0.5 per 1,000 lines of code.
 
 Coding style is considered and enforced in the review of all Cyclone DDS pull requests.
 Contributors are regularly asked to rewrite or reformat their code contributions before pull requests are accepted.