Babeltrace 2.0.0-rc1 release notes

With the convert command’s new automatic source component discovery feature, specify a path, URI, or arbitrary string to let babeltrace2 find the most appropriate components to use:

This means you don’t need to create an explicit component with the --component option most of the time.

Behind the scenes, this feature queries the babeltrace.support-info object from all known component classes: a component class can reply with a confidence score to indicate its ability to handle a given path or custom string.

For example, a source.ctf.fs (CTF trace directory source) component class replies to this query whether or not the given path looks like a CTF trace directory.

This new component pretty-prints all the details of the messages it consumes.

The output is optimized to be human-readable, yet it is deterministic for testing and debugging purposes.

You can use a sink.text.details component to easily inspect messages flowing at any point of a graph and make it easy to test and troubleshoot other component classes.

The Babeltrace 2 project uses this component class for many tests.

A source.ctf.fs component can now open and read malformed CTF traces produced by tracers having known bugs and corner cases (LTTng-UST, LTTng-modules, and barectf).

For example, a source.ctf.fs component can now read data streams which the lttng-crash tool generates, even if the last packets can be malformed.

See the Trace quirks section of the babeltrace2-source.ctf.fs(7) manual page for more details.

Add a sink component to a graph easily using the new simple sink component C API.

A simple sink component is a sink component with a single input port and a single message iterator.

This interface reduces the amount of code you need to write to create a basic Babeltrace 2 message consumer.

Just provide a consumption user function which receives the component’s message iterator to consume upstream messages.

You can also implement other user functions:

Integrate the same automatic source component discovery mechanism which the babeltrace2 CLI’s convert command uses to a Python application using a bt2.TraceCollectionMessageIterator object.

With a bt2.TraceCollectionMessageIterator object, your application can access additional component classes installed on the system from the get go.

New field classes are available in libbabeltrace2 and its Python bindings to support eventual, new CTF 2 field classes.

The new fields are:

Attach custom user attributes to any of the following trace IR objects:

This new property exists because we expect the CTF 2 metadata objects to contain user attributes too.

Report rich error causes from user functions with the new thread-safe error reporting API.

The error reporting API makes it possible for the various actors interacting through libbabeltrace2 to precisely describe the chain of events that lead to a given error. As a library user, you can access this list of causes and reduce the time needed to troubleshoot problems.

This feature is similar to the stack trace which exception objects contain in many programming languages.

When an error occurs, the babeltrace2 CLI uses this error reporting API to show the top-level error itself, but also a detailed list of its causes, for example:

In the Python bindings, raise any exception object as usual from a user function: the bt2 package converts it to a libbabeltrace2 error cause for other parties.

To make the transition from Babeltrace 1 to Babeltrace 2 easier, we decided to make both projects coinstallable thanks to those changes:

Distribution packages will be available for both Babeltrace 1 and Babeltrace 2.

Future-proof component classes using Message Interchange Protocol versioning.

As Babeltrace 2 evolves, we expect to introduce new concepts and objects to libbabeltrace2 such as field class types, message types, methods, and message ordering requirements. To ensure forward and backward compatibility can be maintained across future releases of Babeltrace 2, Babeltrace 2.0.0-rc1 adds the concept of Message Interchange Protocol (MIP).

Should we introduce a breaking change to the protocol which trace processing graph components must honor, we’ll bump the MIP version to announce the modified interface.

You can consider the MIP version as an implicit precondition variable for almost all the libbabeltrace2 functions.

Given the expected initialization parameters, a component class can report a range of supported MIP versions. You can then build a graph which operates with a specific MIP version to ensure all its components exchange messages using the same protocol.

The Babeltrace 2 C API uses the const qualifier liberally to catch many programming errors at compile time.

As the Python language does not have a const feature to express immutability constraints, the Python classes are now split into constant and mutable variants. Mutable variants of the classes have methods to modify and read object properties whereas their constant counterpart only have reading methods.

All constant classes end with Const.

If you try to modify a constant object, Python raises an attribute error.

The Babeltrace 2 packet concept exists because CTF needs it. However, many trace formats don’t.

With Babeltrace 2.0.0-rc1, you don’t need to create packet objects to conceptually contain event objects. As such, you don’t need to emit packet beginning and end messages.

By default, packets are not supported for a given stream class: you need to explicitly enable their support.

The VERBOSE logging level is now the TRACE logging level.

It’s not obvious whether the VERBOSE level is more or less verbose than the DEBUG level. With TRACE instead, it becomes evident.