From: "Jérémie Galarneau" <firstname.lastname@example.org>
Subject: [RELEASE] Babeltrace 2.0.0
Date: Wed, 22 Jan 2020 12:35:51 -0500 [thread overview]
Message-ID: <20200122173551.GA119719@gmail.com> (raw)
This is it: the day you've been waiting for has finally arrived.
Today we're releasing Babeltrace 2.0 “Amqui”! 🥳
Amqui  (/ɒmkwiː/) is a town in eastern Québec , Canada, at the
base of the Gaspé peninsula  in Bas-Saint-Laurent .
Located at the confluence of the Humqui and Matapédia  Rivers, its
proximity to woodlands makes it a great destination for outdoor
activities such as camping, hiking, and mountain biking.
By the way, Babeltrace has a new dedicated domain name:
NOTE: An HTML version of this announcement is available at
Just a few words about why Babeltrace 2 took about five years to
First, let us clarify that from day one, one of the most important
imperatives of the project was **long-term stability**: we wanted
Babeltrace 2 to last for a long time and for its library's API to become
a well-known reference in the trace processing territory, a bit like
Libxml2  has had major version 2 for about 20 years. All the other
Babeltrace 2 parts depend on the library's C API : the command-line
interface  (CLI), the plugins, and the Python bindings.
So, as we needed to modify the library, CLI, and plugins to adapt to new
requirements during the development phase, we postponed the release so
as not to have to release Babeltrace 3 a year after and Babeltrace 4
another year after.
Second, the scope and requirements of the project evolved. Because there
were at most two developers working on Babeltrace 2 at the same time
during its first years, the project took enough time to develop for new
ideas to emerge and translate into changes, sometimes significant, to
the project's modules.
For example, the very first requirement was for the libbabeltrace2 API
to use the same objects as Babeltrace 1's CTF writer API. We put a _lot_
of effort backfitting new concepts into the CTF writer API and making
sure not to break existing user code. But in the end, we realized that
this condition was too limiting and that we had to split the APIs
completely to have the freedom to introduce all the features we wanted.
When the API finally met our needs feature-wise in 2018, we measured and
found that a simple CTF-to-text conversion task with Babeltrace 2 was
approximately 23 times slower than the equivalent with Babeltrace 1!
Hence we entered an optimization phase  in which we had to redefine
core concepts of the library (for example, introduce _unique_ objects to
create object pools ) so that, today, Babeltrace 2's performance is
comparable to Babeltrace 1's .
Revamping the C API to optimize the library means we had to readapt the
CLI, plugins, and Python bindings. We spent the beginning of 2019
synchronizing the project's parts, but also improving and uplifting the
test suite and fixing a lot of lingering bugs.
The last few months were invested in writing a complete C API
documentation  and in more bug fixes, tests, and build system
Today ends this journey to Babeltrace 2.0. It's been a long one, but we
made it. All the next releases of Babeltrace 2 will be minor ones for
the foreseeable future, never breaking the library's API.
Babeltrace 2 is:
* 120,000 lines of C.
* 7000 lines of Python.
* 21,000 tests.
* 30,000 lines of C API documentation.
* 24 manual pages
We hope you enjoy using our software as much as we enjoyed making and
refining it over the last years.
What's new since Babeltrace 1?
The Babeltrace 2 project is completely independent from Babeltrace 1. In
fact, you can install both on the same system as they share no common
files. We only made sure to keep the `babeltrace2` CLI  tool backward
compatible with the original `babeltrace` tool .
See `babeltrace2-intro(7)`  to learn more about Babeltrace 2.
* Full plugin support: any user can distribute a Babeltrace 2 plugin
and, as long as libbabeltrace2 finds it, any application linked to
libbabeltrace2 can load it and use it.
Plugins are not just trace format encoders and decoders: they
package source, filter, and sink component classes so that you can
connect specialized, reusable components together in a trace
processing graph to create a customized trace conversion or
This modular strategy is much like how the FFmpeg ,
GStreamer , and DirectShow  projects approach media stream
* All the parts of the Babeltrace 2 project run on the major
operating systems, including Linux, macOS, and Windows.
* Some component classes, such as `sink.text.pretty`  (similar
to the `text` output format of the `babeltrace` CLI ) and
`sink.text.details` , can write color codes to the standard
output when it's connected to a color-enabled terminal.
The Babeltrace 2 log, printed to the standard output, can also be
* Whereas you can convert traces from one format to another with
Babeltrace 1's CLI tool, `babeltrace` , you can also execute a
custom trace manipulation task with `babeltrace2`  thanks to
its `run`  command.
* The `convert`  command features an automatic source component
discovery algorithm to find the best suited components to create
for a given non-option argument (file or directory path, or custom
string like an LTTng live  URL).
$ babeltrace2 /path/to/ctf/trace
$ babeltrace2 net://localhost/host/myhost/my-session
CTF input/output :
* The `source.ctf.fs`  component class, which is more or less
the equivalent of Babeltrace 1's `ctf` input format, has features
not found in Babeltrace 1:
* The component handles many trace quirks  which are the
results of known tracer bugs (which are fixed today) and corner
cases in LTTng-UST, LTTng-modules, and barectf , making it
possible to decode malformed packets.
* The component merges CTF traces sharing the same UUID into a
single, logical trace .
This feature supports LTTng 2.11's tracing session rotation 
* With a `sink.ctf.fs`  component, you can create CTF traces on
the file system.
With the `babeltrace2` tool, you can use the `--output-format=ctf`
and `--output` options to create an implicit `sink.ctf.fs`
$ babeltrace2 /path/to/input/trace --output-format=ctf \
LTTng live  input:
Babeltrace 1's `babeltrace` command  exits successfully when it
cannot find an LTTng live (`--input-format=lttng-live` option)
The `session-not-found-action`  initialization parameter
controls what a `source.ctf.lttng-live`  message iterator does
when it cannot find the remote tracing session:
* If the action is `end`, the message iterator does like
`babeltrace` and simply ends successfully.
* If the action is `continue` (the default), the message iterator
never ends: it keeps on trying until the tracing session exists,
indeed “subscribing” to the session.
* libbabeltrace2 shares nothing with libbabeltrace.
The Babeltrace 2 library C API  has features such as:
* A single header file.
* Function precondition and postcondition checking.
* Object-oriented model with shared and unique objects.
* Strict C typing and `const` correctness.
* User-extensible classes.
* Rich, thread-safe error reporting.
* Per-component and per-subsystem logging levels.
* Trace intermediate representation (IR) objects to make the API
* A versioned protocol for the exchange of messages between
components to enable forward and backward compatibility.
* You can build the library in _developer mode_ to enable an
extensive set of function precondition and postcondition checks.
The developer mode can help detect programming errors early when
you develop a Babeltrace 2 plugin or an application using
See the project's README  for build-time requirements and
detailed build instructions.
Python 3 bindings:
* The new `bt2` package offers all the functionality of
libbabeltrace2 and even more through a brand new, Pythonic
* With the `bt2` package, you can load existing plugins and create a
trace processing graph, but also create Babeltrace 2 plugins.
libbabeltrace2 can load both shared object and Python plugins.
* What has the `const` qualifier in libbabeltrace2 has a dedicated
constant type in the `bt2` package so that methods to modify it
simply do not exist. This can help catch programming errors.
For example, when you create an event message, you get a
`bt2._EventMessage` object. When you consume an event message, you
get an immutable `bt2._EventMessageConst` object. Both objects
wrap the same C `bt_event *` (and `const bt_event *`) object.
What's new since Babeltrace 2.0.0-rc4?
* Hide private symbols.
* Add a mechanism to add extra information (name, description, and
names of applied patches) to a custom build's version.
Print full version, including the release's name and name
description, the Git revision's description, and the extra
information, with the `--version` option.
Write a comprehensive Babeltrace 2 library C API documentation .
* Remove the `bt_packet_context_field` API (not needed anymore).
* Standardize variant field option function names.
* Graph API: remove “ports connected” listeners (not needed
* Graph API: remove the “listener removed” callbacks (not needed
* Remove `bt_graph_interrupt()`; use the new
`bt_graph_borrow_default_interrupter()` function instead.
* Remove `bt_query_executor_interrupt()`; use the new
`bt_query_executor_borrow_default_interrupter()` function instead.
* Add the _message iterator class_ concept.
Instead of having an implicit message iterator class within source
and filter component classes, make its creation explicit and pass
it to `bt_component_class_source_create()` and
See `68e2deed`, `8e1fe2a4`, and `f615b250`.
* Rename `BT_PLUGIN_INITIALIZE()` to `BT_PLUGIN_INITIALIZE_FUNC()`
and `BT_PLUGIN_FINALIZE()` to `BT_PLUGIN_FINALIZE_FUNC()`.
* For many functions of the graph and component APIs, return a
_borrowed_ reference of an added object instead of a new
* Rename `bt_version_get_extra()` to
* Add the following functions to get more information about the
See `2491e1b5`, `58df4c80`, and `a0446fa8`.
* Adapt to the library changes above.
* Make `bt2.Graph.add_*_listener()` return `None`.
* Reverse the order of the printed causes in `bt2._Error.__str__()`
to match what the CLI does.
`source.ctf.fs` component class :
Sort the paths of the data stream files to handle so that the output
port order is predictable (for debugging purposes).
Notable bug fixes
Print error causes in all error paths.
* Fix shared reference issues in listener handles.
* Don't print previous error causes in causes created from
The current road map includes:
* Make it easier to create an efficient filter message iterator which
needs to modify or augment event messages.
Currently, if you need to modify an event message, considering that
you cannot change an event class once you use it, you need to create a
new event class, which means you also need to create a new stream
class and a new trace class. You also need to copy all the metadata
and data objects you don't alter. This is what
`filter.lttng-utils.debug-info`  does.
We do realize that trace-transforming filter message iterators
represent an important Babeltrace 2 use case. While it's possible to
write one for Babeltrace 2.0, it is cumbersome to do and the result is
not as performant as we'd like. We decided to release Babeltrace 2 now
and reserve improvements to this part of the library for a future
* Add a filter component class to drop messages (like events) based on a
filter expression, similar to the `--filter` option  of the
* Make the `ctf`  plugin's component classes support CTF 2, the
upcoming major revision of the Common Trace Format .
* Optimize specific project component classes, especially
`source.ctf.fs` , `source.ctf.lttng-live` , and
For `source.ctf.fs`, implement the “seek ns from origin” method using
the packet indexes to make a message iterator seek a specific time
== Important links
Babeltrace 2.0.0 tarball:
Mailing list (for support and development):
`#lttng` on `irc.oftc.net`
reply other threads:[~2020-01-22 17:35 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).