config_parse.py: fix PEP 8 errors, as reported by `flake8`

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>

tox.ini: make `flake8` ignore `templates.py`

`templates.py` is only a bunch of strings; no application code there.

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>

tox.ini: run `flake8` for the `barectf` directory only

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>

config_parse.py: comment `_ConfigParseErrorCtx` and `_ConfigParseError`

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>

_YamlConfigParser: rename field type creation methods (more explicit)

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>

_YamlConfigParser: rename `_root_yaml_path` 👉 `_root_path`

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>

config_parse.py: use a `_YamlConfigParser` object a single time

This patch changes `_YamlConfigParser` so that you can only use it once:
the object parses the file on construction, and then makes the
configuration object available through its `config` property.

Because you can't parse another file with the same parser, we don't need
to care about any stale state.

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>

config_parse.py: normalize exception contexts and messages

This patch also changes the terminology of the messages to use "type"
and "field type" as much as possible, for example "event type",
"stream type", and "integer field type".

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>

config_parse.py: update/improve comments

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>

barectf: rename `ConfigParseError` 👉 `_ConfigParseError`

This is not a class which the API user can instantiate.

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>

barectf: use JSON schema to validate special root field type fields

This patch removes almost everything from the
`_MetadataSpecialFieldsValidator` class, moving those checks to the
`schemas/2/config/config.yaml` JSON schema instead.

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>

barectf: schemas: use conditionals intead of `oneOf` when possible

Using `if`/`then`/`else` instead of `oneOf` makes the `jsonschema`
validator create much more readable errors.

For example:

Before:
    Error:
      Configuration: Cannot create configuration from YAML file
        `config.yaml`
      Configuration object:
      `metadata` property:
      `clocks` property:
      `some_clock` property:
      `offset` property:
      `seconds` property: -2 is not valid under any of the given
        schemas: -2 is less than the minimum of 0; -2 is not of type
        'null' (from schema `2/config/config`)

Now:
    Error:
      Configuration: Cannot create configuration from YAML file
        `config.yaml`
      Configuration object:
      `metadata` property:
      `clocks` property:
      `some_clock` property:
      `offset` property:
      `seconds` property: -2 is less than the minimum of 0
        (from schema `2/config/config`)

This is because, with conditionals, we assume that the user intended
something with some valid schema, and add more constraints. The example
above is for an integer having a minimum value of 0, or a null value. As
soon as we know that the value is an integer, then we know its minimum
must be 0; we decide to not care about the fact that the whole value
could also be null (which the old message indicated). In my opinion,
this is a better UX.

The example above is simple. For more complex schemas, the UX gain is
even more obvious.

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>

_SchemaValidator.validate(): use "element" prefix for array elements

Otherwise the context's object name would be:

    `2` property

instead of

    Element 2

for example.

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>

LICENSE: reflow licence header for 72 columns

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>

LICENSE: update copyright years

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>

barectf: reflow licence headers for 72 columns

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>

barectf: update copyright years

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>

gen.py, templates.py: replace double quotes with backticks (generated)

Style preference.

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>

cli.py, config_parse.py: replace double quotes with backticks

Style preference.

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>

Use JSON schemas to validate the layout and types of the YAML config.

This patch changes `config_parse.py` so as to use JSON schemas
(<https://json-schema.org/>) to validate many aspects of a barectf YAML
configuration file instead of having redundant, manual checks.

JSON schemas are found in the `barectf` package's `schemas` directory by
an instance of the new `_SchemaValidator` class. Such an object finds
all the YAML files in the `schemas` directory and, for each of them:

1. Loads it (YAML to Python dictionary).
2. Gets its ID (`$id` property).
3. Adds the schema (1.) to a local schema store using its ID (2.).

Then _SchemaValidator.validate() uses this schema store to build a JSON
schema reference resolver and validator from the `jsonschema` package
(<https://pypi.org/project/jsonschema/>).

The `jsonschema` dependency is added to `pyproject.toml` and
`poetry.lock`. We need a version which supports JSON Schema draft 7
because we need the conditional keywords (`if`/`then`).

Because the barectf YAML configuration file format supports features
which do not exist natively in YAML (inclusions, field type aliases,
field type inheritance, and log level aliases), we can't have a single
JSON schema for the "raw" configuration file. There are actually five
validation steps, each one having its JSON schema:

1. Make sure the configuration object is minimally valid, that is, it's
   an object and has a `version` property with a supported value.

   Schema: `config/config-min.yaml`.

2. Make sure the configuration object is valid for the inclusion phase.

   Those schemas only validate that the metadata/stream/event objects
   are objects and that any `$include` property is valid.

   Each time the YAML configuration parser loads a partial YAML file for
   inclusion, it validates the resulting object using the corresponding
   schema depending on what's being included.

   Knowing those objects are valid as such is enough to process
   inclusions without caring about the resulting configuration object's
   validity.

   Schemas:

   * `2/config/clock-pre-include.yaml`
   * `2/config/config-pre-include.yaml`
   * `2/config/event-pre-include.yaml`
   * `2/config/include-prop.yaml`
   * `2/config/metadata-pre-include.yaml`
   * `2/config/stream-pre-include.yaml`
   * `2/config/trace-pre-include.yaml`

3. Make sure the configuration object is valid for the field type
   expansion phase.

   This schema digs into compound field types recursively to make sure
   any field type is either a string (field type alias) or an object
   with either a `class` property or an `$inherit`/`inherit` (mutually
   exclusive) property.

   Knowing the configuration object is valid as such is enough to expand
   field types without caring about the resulting configuration object's
   validity. So, for example, a resulting, expanded field type could be:

       class: string
       size: 16
       value-type:
         class: array
       meow: mix

   We just don't care at this point, as long as field types are
   "complete".

   Schema: `2/config/config-pre-field-type-expansion.yaml`.

4. Make sure the configuration object is valid for the log level
   expansion phase.

   This schema validates the `$log-levels` property of the metadata
   object as well as the `log-level` property of any event object.

   Knowing the configuration object is valid as such is enough to expand
   log levels, that is, to replace log level strings with their numeric
   value, without caring about the resulting configuration object's
   validity.

   Schema: `2/config/config-pre-log-level-expansion.yaml`.

5. Make sure the configuration object is valid.

   This validates the final, effective configuration object which, at
   this point, do not contain any:

   * `$include` properties.
   * Strings as field types.
   * `$inherit`/`inherit` properties (field type objects).
   * `$log-levels` property (metadata object).
   * Strings for the `log-level` properties (event objects).

   Also, this is the configuration object which the `--dump-config`
   option prints now.

   * `2/config/byte-order-prop.yaml`
   * `2/config/config.yaml`
   * `2/config/field-type.yaml`
   * `2/config/uuid-prop.yaml`

After step 5., there's not much to validate in `config_parse.py` itself:

* Make sure referred clock type objects (in `property-mappings` properties
  of integer field type objects) exist.

* Make sure identifiers are valid (the schemas do not always validate
  that they exclude CTF keywords for technical reasons).

* Make sure alignment values are valid (powers of two).

* Make sure there's only one default stream type name and that it
  exists.

* Make sure the values of enumeration field type members are within the
  field type's range depending on the value (integer) field type's size.

* Everything that remains in `_BarectfMetadataValidator`.

* Everything in `_MetadataSpecialFieldsValidator`, which is untouched
  because that's not something we validate with JSON schemas, although
  we could possibly, but it might stretch the use case.

_SchemaValidator.validate() catches a `jsonschema` exception and
converts it to a barectf `ConfigParseError` exception to avoid leaking
`jsonschema` objects (implementation detail) from barectf calls. I made
an effort to make the error object as readable as possible, for example
converting the instance path to context object names, but there's room
for improvement here.

No functional change intended, except for the modified raised
`ConfigParseError` objects. Tests are not changed and pass.

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>

config_parse.py: add _append_error_ctx() to remove redundant code

_append_error_ctx() appends context to a given `ConfigParseError`
exception and then reraises it.

Using

    catch ConfigParseError as exc:
        _append_error_ctx(exc, 'My object', 'My message')

instead of

    catch ConfigParseError as exc:
        exc.append_ctx('My object', 'My message')
        raise

makes sure we don't forget to reraise.

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>

Make configuration and metadata objects immutable

This patch changes how configuration and metadata objects are built.

Before this patch, the YAML configuration parser in `config.py` created
default metadata objects and then set their properties as it parsed the
YAML node.

Having such mutable objects means they can change at anytime once they
exist.

This patch changes this so that all configuration and metadata objects
accept all they need at construction time and do not offer setters.

`config.py` now only contains the `Config` and `ConfigOptions` classes
as well as the from_file() function. All the YAML parsing and
configuration/metadata construction is in `config_parse.py`.

In `config_parse.py`, there are mutable "pseudo" classes which
correspond to the immutable versions. They are only used during the
parsing stage and, at the end, converted to their public, immutable
equivalents.

The configuration validation is done at the YAML/pseudo level, which
means the public configuration/metadata classes do not validate anything
(narrow contract). Their constructors _should_ at least assert that
everything looks okay, but this work is not part of this patch.

No functional changes intended by this patch at the CLI level, which is
why all tests still pass without modification.

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>

Capitalize exception messages and what the CLI prints

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>

test.bash: pass all `.bats` files to `bats`

This makes `bats` accumulate tests and run all of them with a global
progress, which is much better.

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>

barectf_config_check_fail(): check that failure is caused by cfg. error

This patch makes barectf_config_check_fail() in `config/common.bash`
check that the output of `barectf` contains the string

    configuration: cannot create configuration

so as to ensure that the failure is _at least_ caused by a configuration
error, even if we don't know if the real failure cause matches what the
test intends to verify.

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>

tests/config/pass/everything/pass.bats: quote `$CC`

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>

tests/config/pass/everything/pass.bats: make test directory the CWD

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>

tests/config/fail/yaml/invalid.yaml: fix invalid YAML (list/neg. value)

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>

cli: print traceback for unknown exceptions

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>

Append context to a `ConfigError` instead of wrapping another exception

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>

Remove everything related to CTF sequences and variants

Those CTF types are not supported by barectf currently, yet some code
was written to support them at the configuration level. This is some
rather complex (dead) code to resolve field paths and validate those
types, but without anything to test it. In fact, the code exists to
parse a variant type, for example, but barectf fails with an error (not
supported) when you do so.

The code is still in this repository's history; let's add it back when
we can really test it.

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>

Convert project to a Poetry project

Poetry <https://python-poetry.org/> handles the build creation and
`setup.py` and `PKG-INFO` generation.

Poetry also handles dependencies and can create a corresponding virtual
environment having them installed.

Poetry can also publish.

`poetry.lock` was generated by `poetry install` and ensures this
specific version of barectf is tested with those specific versions of
the dependencies.

Setuptools is a run-time dependency for its `pkg_resources` package. I
use `*` for its version constraint because somehow Poetry needs
Setuptools itself so it skips this dependency (see
<https://github.com/python-poetry/poetry/issues/1584>). The `setuptools`
dependency still ends up in `setup.py`.

`tox.ini` is calibrated so that tox doesn't manage any dependency;
everything is done through Poetry (except `flake8` which doesn't need
barectf to be installed).

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>

barectf/__init__.py: build version string instead of parsing it

This is more natural and less complicated.

Leaving get_version_tuple() as some modules use it.

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>

Add git-review config

Signed-off-by: Michael Jeanson <mjeanson@efficios.com>
Change-Id: I12ee3f57fc2e9cafb74cd489add4f8dbb89b2ca9

barectf v2.3.1

Signed-off-by: Philippe Proulx <pproulx@efficios.com>
Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>

Fix: do not sample clock when closing/opening a packet for an event not fitting

This patch adds members to the generated barectf context to save the
current (becomes last) event's timestamp and use it when closing and
opening packets when the event does not fit the current packet instead
of sampling the clock again.

Without this patch, with this scenario:

1. Application calls a tracing function.
2. Tracing function samples the clock.
3. Event does not fit the current packet size: current packet is closed,
   sampling the clock, and new packet is opened, also sampling the
   clock.
4. Event is serialized to the new packet.

The new packet's timestamp is greater than its first event's timestamp,
because this event's timestamp is the result of sampling the clock
before sampling it to close the current packet and open a new one.

Babeltrace 1 accepts and reads the resulting stream, but Babeltrace 2's
muxer is more strict and refuses a message which is in the past.

Signed-off-by: Philippe Proulx <pproulx@efficios.com>
Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>

Fix: use the same actions to compute event size and to serialize

Issue
=====
In `gen.py`, the code to generate the event size computation C code and
the event serialization C code are not the same. There are optimizations
to avoid generating useless alignment statements in one which are
missing in the other, and those optimizations have a bug. This bug can
lead to the space reservation phase of a tracing function passing
(enough space for a given event to serialize), but the serialization
phase writing passed the end of the packet buffer.

Solution
========
Make barectf use the exact same actions to generate the event size
computation C code and the event serialization C code.

In `gen.py`, `_SerializationActions` is a new class of which you can
use an instance to append a root scope field type
(_SerializationActions.append_root_scope_type()) and to retrieve a list
of resulting serialization actions. The two types of serialization
actions are:

`_AlignSerializationAction`:
    Force the alignment of the current bit position within the packet.

`_SerializeSerializationAction`:
Serialize a field from a given type.

Each action object contains:

* An optional field type which is responsible for the action.
* An offset within the current byte when this action needs
  to be executed (to generate the appropriate bt_bitfield_write_*()
  calls).
* A list of names which identify this action (complete field name/path).

_SerializationActions.append_root_scope_type() performs the necessary
optimizations (does not align when specific conditions are met to avoid
a useless alignment statement). Then those optimizations apply to both
the event size computation and event serialization C code, the only
difference being that the event size computation code adds to a partial
sum variable instead of writing to the packet buffer.

The alignment optimization technique is straightforward at this point
and could be improved: if the alignment requirement did not change since
the last alignment, and if there's no padding between a field and the
previous field, then do not align for this field; otherwise, align.

Known drawbacks
===============
Because the alignment optimization technique is changed to be simpler,
some barectf configurations could make barectf generate more C code
(which means more compiled code and slower execution eventually).
However, the previously generated C code was incorrect anyway.

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>

barectf v2.3.0

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>

tox.ini: no `pep8` env by default, fix testenv:pep8 env

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>

barectf/config.py: fix whitespaces (PEP 8)

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>

tox: Add usedevelop

Signed-off-by: Michael Jeanson <mjeanson@efficios.com>

Fix: fail tests succeed on env failure

Signed-off-by: Michael Jeanson <mjeanson@efficios.com>

tests/common.bash: use $status, not $?, when using `run`

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>

Merge branch 'tox' of https://github.com/mjeanson/barectf

Add tox support

Signed-off-by: Michael Jeanson <mjeanson@efficios.com>

Merge branch 'master' of https://github.com/mjeanson/barectf

Fix: templates.py: call bt_piecewise_rshift() with _vtype (BE)

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>

Fix: return proper exit code on test failure

Signed-off-by: Michael Jeanson <mjeanson@efficios.com>

linux-fs-simple example Makefile: make platform depend on barectf.h

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>

Add tracing activity and tracing section API

The new barectf_is_tracing_enabled() function allows the instrumented
program to enable or disable tracing for a specific barectf context.
This is a thread-safe API, in that it only sets a member of the context
to 0 or 1. Disabling the tracing activity does not guarantee, however,
that the current packet or back-end is not currently being altered. See
the next paragraph about this.

The new barectf_is_in_tracing_section() function allows the instrumented
program to know if its tracing thread is currently in a barectf section
or not. barectf_is_in_tracing_section_ptr() returns a volatile pointer
to this same information.

Both functions can be used together to implement a snapshot action for a
given platform, something like:

1. The instrumented thread calls the barectf tracing functions during
   its execution. When a packet is closed, the platform appends it to a
   ring buffer, overwriting the oldest recorded one if there's no space
   left. This is called a flight recorder mode.
2. The controller (another thread of the instrumented program, or an
   external host) recognizes a trigger where we would only need the
   latest data to analyze the situation. Therefore tracing must be
   stopped, because we don't want the current ring buffer packets to be
   overwritten anymore.
3. The controller disables tracing. It is safe to call
   barectf_is_tracing_enabled(ctx, 0) from another thread.
4. When barectf_is_tracing_enabled(ctx, 0) is called, the barectf
   tracing function currently being executed still needs to finish. At
   this point it could still alter the current packet. Therefore the
   controller waits until barectf_is_in_tracing_section() is 0.
5. Once barectf_is_in_tracing_section() returns 0, it won't return 1
   until barectf_is_tracing_enabled(ctx, 1) is called again, so it is
   safe to read the ring buffer, and also to read the current packet.

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>

README.md: fix links

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>

barectf v2.2.1

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>

README.md: update content

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>

doc/examples: use -ansi flag to ensure ANSI C compatibility

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>

barectf(1): write short option's argument too

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>

Claim to generate ANSI C code

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>

Remove <stdint.h> include in generated bitfield.h

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>

Remove unused macros from generated bitfield header

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>

gen.py: put union variable at the top of a nested block

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>

Remove dependency on GNU C extensions

__typeof__() dependency is removed by passing the type to the
macro explicitly.

Statement expression dependency is removed by using an in/out
macro parameter instead.

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>

Support C++ build of generated and linux-fs platform files

Mostly void * casting stuff.

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>

barectf-platform-linux-fs.h: add __cplusplus check

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>

barectf.c: remove unused _packet_is_full()

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>

barectf.h: add __cplusplus check

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>

Merge pull request #11 from mjeanson/master

Update CI link in README.md

Update CI link in README.md

Signed-off-by: Michael Jeanson <mjeanson@efficios.com>

Refer to official website barectf.org

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>

Add MIT license header to generated files

Fixes: #8
Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>

Fix package name in Ubuntu install instructions

Make sure all source files have a MIT license header

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>

examples/barectf-tracepoint: fix comment

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>

doc/man: update man page's date and version

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>

barectf v2.2.0

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>

docs/examples/.gitignore: ignore "metadata"

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>

barectf-tracepoint: add QEMU ARM target example

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>

barectf-tracepoint ex: rename "barectf" -> "barectf-linux-fs"

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>

barectf-tracepoint ex: put platform-specific stuff in separate files

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>

doc/examples/linux-fs-simple: use $(BARECTF), no view target

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>

Add doc/examples/barectf-tracepoint

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>

Add extra/barectf-tracepoint.h (tracepoint() macro wrapper)

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>

tests/config/fail/stream: add tests for "$default" prop

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>

tests/config/fail/metadata: add tests for default stream name

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>

tests/config/fail: remove .c/.h files

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>

tests/config/pass/everything: fix gen-default-stream-def

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>

doc/examples/linux-fs-simple: generate prefix/def stream name defs

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>

tests/config/fail/config: remove options-gen-default-stream-def-unknown-stream-name

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>

Make config option "gen-default-stream-def" a boolean

Now that there's a way to specify a default stream, we only
need to know if we want or not to generate this definition.

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>

doc/examples/linux-fs-simple: use 2.2 config with default stream

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>

gen, templates: generate default stream trace definitions

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>

config: specify default stream in metadata/stream objects

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>

gen, templates: generate prefix/default stream definitions

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>

tests/config/pass/everything: add config options to test

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>

tests/config/fail/config: add config options tests

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>

config: add configuration options

Current options:

  * `gen-prefix-def`: generate a prefix definition in the
    header file
  * `gen-default-stream-def`: generate a default stream
    name definition in the header file

Those are intended to facilitate the use of a barectf-LTTng-UST
adapter.

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>

barectf v2.2.0-dev

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>

README.md: specify Ubuntu versions

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>

README.md: add PPA instructions for Ubuntu

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>

README.md: add AUR package instructions for Arch Linux

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>

README.md: "philosphy" -> "philosophy"

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>

barectf v2.1.4

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>