Last commit made on 2023-08-16
Get this branch:
git clone -b master

Branch merges

Branch information


Recent commits

fdacbf1... by Erica Bugden <email address hidden>

docs: cleanup: Rephrase and correct typos

    - Facilitate understanding for beginners (Make sentence structure
      more explicit, Use more explicit terms)

    - "recommandation" --> "recommendation"
    - Remove "as its document"

Change-Id: I00e123a348cb90b53aed5effcde7f9ecdbbae453
Signed-off-by: Erica Bugden <email address hidden>

3fabb0e... by Erica Bugden <email address hidden>

docs: fix: Update outdated term `target-byte-order`

`target-byte-order` was renamed to `native-byte-order` in commit
313a0bd9517a .

Change-Id: If72b59d810a989da9009d22d8c2b2ef7df72c495
Signed-off-by: Erica Bugden <email address hidden>

f9d5d8b... by Kienan Stewart <email address hidden>

fix: Update pyyaml to avoid build failures with cython 3

pyyaml 5.4 fails to build with Cython >= 3.0.0a10 on both Ubuntu jammy and
Debian 12, causing this project's build to fail with the following

  Traceback (most recent call last):
    File "/tmp/tmp.b5DvVvhyNr/lib/python3.11/site-packages/pyproject_hooks/_in_process/", line 353, in <module>
    File "/tmp/tmp.b5DvVvhyNr/lib/python3.11/site-packages/pyproject_hooks/_in_process/", line 335, in main
      json_out['return_val'] = hook(**hook_input['kwargs'])
    File "/tmp/tmp.b5DvVvhyNr/lib/python3.11/site-packages/pyproject_hooks/_in_process/", line 118, in get_requires_for_build_wheel
      return hook(config_settings)
    File "/tmp/tmp9j5cmxoa/.venv/lib/python3.11/site-packages/setuptools/", line 341, in get_requires_for_build_wheel
      return self._get_build_requires(config_settings, requirements=['wheel'])
    File "/tmp/tmp9j5cmxoa/.venv/lib/python3.11/site-packages/setuptools/", line 323, in _get_build_requires
    File "/tmp/tmp9j5cmxoa/.venv/lib/python3.11/site-packages/setuptools/", line 338, in run_setup
      exec(code, locals())
    File "<string>", line 271, in <module>
    File "/tmp/tmp9j5cmxoa/.venv/lib/python3.11/site-packages/setuptools/", line 107, in setup
      return distutils.core.setup(**attrs)
    File "/tmp/tmp9j5cmxoa/.venv/lib/python3.11/site-packages/setuptools/_distutils/", line 185, in setup
      return run_commands(dist)
    File "/tmp/tmp9j5cmxoa/.venv/lib/python3.11/site-packages/setuptools/_distutils/", line 201, in run_commands
    File "/tmp/tmp9j5cmxoa/.venv/lib/python3.11/site-packages/setuptools/_distutils/", line 969, in run_commands
    File "/tmp/tmp9j5cmxoa/.venv/lib/python3.11/site-packages/setuptools/", line 1234, in run_command
    File "/tmp/tmp9j5cmxoa/.venv/lib/python3.11/site-packages/setuptools/_distutils/", line 988, in run_command
    File "/tmp/tmp9j5cmxoa/.venv/lib/python3.11/site-packages/setuptools/command/", line 314, in run
    File "/tmp/tmp9j5cmxoa/.venv/lib/python3.11/site-packages/setuptools/command/", line 322, in find_sources
    File "/tmp/tmp9j5cmxoa/.venv/lib/python3.11/site-packages/setuptools/command/", line 551, in run
    File "/tmp/tmp9j5cmxoa/.venv/lib/python3.11/site-packages/setuptools/command/", line 589, in add_defaults
    File "/tmp/tmp9j5cmxoa/.venv/lib/python3.11/site-packages/setuptools/command/", line 104, in add_defaults
    File "/tmp/tmp9j5cmxoa/.venv/lib/python3.11/site-packages/setuptools/_distutils/command/", line 251, in add_defaults
    File "/tmp/tmp9j5cmxoa/.venv/lib/python3.11/site-packages/setuptools/_distutils/command/", line 336, in _add_defaults_ext
    File "<string>", line 201, in get_source_files
    File "/tmp/tmp9j5cmxoa/.venv/lib/python3.11/site-packages/setuptools/_distutils/", line 107, in __getattr__
      raise AttributeError(attr)
  AttributeError: cython_sources

The upstream issue is and
there are two possible solutions:

* Update pyyaml
* Constrain the version of cython

Change-Id: I2c7b8f33bcbc5c3a0a60578e2d0dd74cdca4f2ba
Signed-off-by: Kienan Stewart <email address hidden>

1d62391... by Erica Bugden <email address hidden>

tests: Verify build fails with mismatched byte order

This tests the byte order check added in the previous commit `Check that
native byte orders match at compilation`.

Change `byte-order-yes.yaml`:

This test configuration now defines the tracer byte order with
`native-byte-order: big-endian` (instead of
`trace-byte-order: big-endian`) so that this configuration can be used
both for the configuration tests and for the new byte order check test.
The `native-byte-order` property is used so that the C preprocessor
check will be present in the generated C code. The byte order is set to
`big-endian` so that building the generated C will fail on a
little-endian system.

This change does not reduce the test coverage because:
    a. `byte-order-yes.yaml` still tests that using one of the two byte
       order properties is a valid configuration, and
    b. The `trace-byte-order` property is tested via
       `trace-byte-order-big-endian.yaml` in the tracing tests.

Change-Id: Ic2aa7bdc7e56881233efe2e25153dc4e65ba309a
Signed-off-by: Erica Bugden <email address hidden>

9e49bad... by Erica Bugden <email address hidden>

Check that native byte orders match at compilation


In barectf 3, the tracer's byte order is typically defined by the
'native-byte-order' property in the barectf yaml configuration.

When the tracer's configured native byte order does not match the
tracing target system's native byte order, it is not immediately obvious
that there is a problem. The generated tracer will build successfully
and, after integrating the tracer, tracing data will be generated.
However, if the user attempts to open the trace (e.g. with babeltrace),
it will fail. This is because the expected structure of the
trace data (described by the trace's metadata file) will not match the
actual structure of the generated trace data and so the trace reader
will not be able to parse the trace data. Because the issue only reveals
itself when reading the traces, it is challenging to identify it as a
tracer configuration error.


When the tracer's byte order is defined by the 'native-byte-order'
property, add a byte order check at compilation time to prevent building
a little endian tracer for a big endian system (or vice versa). This
check is made at compilation time since the native byte order
(endianness) of the compilation target system can only be detected at
compilation time. This is the earliest moment it can be automatically
detected that the generated tracer has been misconfigured.


In barectf 3, there are currently two different properties that can be
used to configure the byte order of the generated traces:

    - 'native-byte-order': The recommended byte order property.
       Implemented via the 'TraceType' class.
    - 'trace-byte-order': Required for supporting barectf 2
       configuration files. Implemented via the
       'TraceTypeWithUnknownNativeByteOrder' class.

In 'barectf.c.j2', the byte order check should be performed when the
'native-byte-order' property is used, so the preprocessor checks are
included when the trace type class is 'TraceType'.

The byte order check is made using GCC common predefined macros. These
macros may not always be defined by the C compiler used to build the
barectf tracer, especially considering that barectf is designed for use
in embedded scenarios where tool chains are varied. In the case where
the byte order macros are not defined and the byte order cannot be
verified automatically, we choose not to warn the user because showing
a warning each time a barectf tracer is compiled could become
frustrating for users.

Test change:

Change 'tests/config/yaml/2/configs/pass/everything/config.yaml' to
little endian byte order (le) from big endian since otherwise the test
now fails.

    Note: The current barectf tests implicitly assume that the tests are
    run on a little endian system. All the tests under 'tests/tracing'
    will fail if run on a big endian system.

Change-Id: I3b084bb0084cf418371ef1ccec0d9f69ec26b814
Signed-off-by: Erica Bugden <email address hidden>

0e5d2a6... by Erica Bugden <email address hidden>

tests: cleanup: Clarify test file does not exist

Change-Id: I8bff99e24ae7c25f1fb9fce3b4f3e616f839b2f6
Signed-off-by: Erica Bugden <email address hidden>

0ea3b42... by Erica Bugden <email address hidden>

tests: cleanup: Explain the purpose of some tests

Tests explained:
    * test_everything() (see note below)
    * `include` test cases

Identifying the intended purpose of the `include` test cases is a
partial prerequisite for the future work of checking that each
configuration test expecting a failure fails for the intended reason. At
the momment, we only check that configuration fails regardless of the

Note: test_everything() is a single stand alone test case that dates
back to from barectf 2 before the `tracing` tests existed. This is why
it checks more than just configuration generation. It is possibly
redundant with the more extensive tracing tests.

Change-Id: I59fe258b4f1eb7ef5c83f717f12973d38269adb4
Signed-off-by: Erica Bugden <email address hidden>

b2fd4fd... by Erica Bugden <email address hidden>

tests: cleanup: Remove dead $include-replace tests


The $include-replace property appears to have been removed sometime in
the past. These 3 test cases are the only remaining references to this
property in the code base. The last reference to $include-replace in the
log is in commit 6839ffb (Use JSON schemas to validate the layout and
types of the YAML config) in `` at lines 2693-2694 where
the following comment referring to the property is removed:

    # In each object, only one of the $include and $include-replace
    # special properties is allowed.

All of this seems to point to this property no longer existing.


Remove test cases referring to the $include-replace property.

Change-Id: I71d3293acf3518ebe5812db7fc9cc07ed933f64e
Signed-off-by: Erica Bugden <email address hidden>

8d81378... by Erica Bugden <email address hidden>

tests: fix: Run packet-set-buf tracing test


Currently, the packet-set-buf test is not run even though the test was
added as a regression test for a bug fix (0a5733a). The fix commit
message says:

    Adding a test with a custom platform calling
    barectf_packet_set_buf() with a `NULL` buffer after closing a
    completely full packet. Without this patch (in `barectf.c.j2`), this
    test leads to a segmentation fault.

It looks like this new test case was accidentally not added to the list
of valid test categories:

    * Sep 24, 2020 - Filter for valid test categories added (in 5b906ca)
    * Oct 6, 2020 - packet-set-buf test added, but not to valid
       categories (in 0a5733a)


Add `packet-set-buf` to the valid test categories so the test will run.

Change-Id: I43a90bafe08897eaf107336fd8b629bad512b996
Signed-off-by: Erica Bugden <email address hidden>

0ab7651... by .eepp

README.adoc: fix CI build badge

Signed-off-by: Philippe Proulx <email address hidden>
Change-Id: I6644dae7b8b46444d28e609e8c15bccc5f7bac4e