Babeltrace 2 C API 2.1.0
Open-source trace manipulation framework
|
Babeltrace 2.1 introduces new trace IR features under the new version 1 of the Message Interchange Protocol (MIP).
This guide shows the differences between MIP 0 and MIP 1 along with how to update your component class, which already supports MIP 0, to also support MIP 1.
Even though you could implement the "get supported MIP versions" component class method in Babeltrace 2.0, you didn't have to because without it, the default supported MIP version is 0, which was the only available one anyway.
Starting from Babeltrace 2.1, your component may support MIP 0, MIP 1, or both. It's now mandatory to implement the "get supported MIP versions" method to support MIP 1 as the bt_graph_add_source_component_with_initialize_method_data(), bt_graph_add_filter_component_with_initialize_method_data(), and bt_graph_add_sink_component_with_initialize_method_data() functions have the following precondition:
To make your component indicate MIP 1 support:
In your plugin definition C file, use the BT_PLUGIN_SOURCE_COMPONENT_CLASS_GET_SUPPORTED_MIP_VERSIONS_METHOD(), BT_PLUGIN_FILTER_COMPONENT_CLASS_GET_SUPPORTED_MIP_VERSIONS_METHOD(), or BT_PLUGIN_SINK_COMPONENT_CLASS_GET_SUPPORTED_MIP_VERSIONS_METHOD() macro to set the "get supported MIP versions" method of your component class.
For example:
In your "get supported MIP versions" method, include version 1 in the supported version range.
For example, to show support for both MIP 0 and MIP 1:
You may rely on params and initialize_method_data to determine the exact MIP versions your component class instances expect to support.
Although most API functions work identically with both MIP 0 and MIP 1, some of them are only valid for a specific MIP version.
In a component or message iterator method, especially if your component supports both available versions of the MIP, you might need to decide which API function to use at run time depending on the current, effective MIP version of the trace processing graph.
The available MIP version access functions are:
For example, in a sink component printing the details of a trace, you may only get its namespace under MIP 1:
MIP 1 brings the required changes to support the features of CTF 2. As such:
Clock class, event class, stream class, and trace objects may have a namespace, a name, and a unique ID (UID).
The UUID property of clock class and trace objects is removed in favor of the new UID property.
The following subsections provide details about the changes above and how MIP 0 translates to MIP 1 in their context.
The clock class, event class, stream class, and trace objects may have a namespace, a name, and a unique ID (UID).
Together, we call those three optional properties the identity of an object.
Babeltrace 2 doesn't specify what's the purpose of an identity and why you should use it, except for clock classes: it exists to accomodate trace formats.
On creation, an object has no identity (the values of the namespace, name, and UID properties are missing).
For clock class and trace objects, MIP 1 removes the UUID property in favor of those new properties. In other words, you cannot use the following functions with MIP 1:
A good strategy is to set the UID property to the textual representation of the UUID instead.
The new identity property access functions are:
Object | Namespace access | Name access (also valid with MIP 0) | UID access |
---|---|---|---|
Clock class | |||
Event class | |||
Stream class | |||
Trace |
The clock class API is changed as such from MIP 0 to MIP 1:
The identity is the namespace, name, and UID tuple instead of the name and UUID pair.
See the Namespace, name, and unique ID section above.
The precision property is optional.
bt_clock_class_create() makes the initial precision unknown.
Use the new bt_clock_class_get_opt_precision() function to get whether or not the precision is known and, if it's known, its value.
bt_clock_class_get_precision() is not available and becomes deprecated.
There's a new, optional accuracy property.
The accuracy value is in clock cycles.
While the precision property describes the random errors of clocks, the accuracy property describes systematic errors. From Accuracy and precision:
bt_clock_class_create() makes the initial accuracy unknown.
Use the new bt_clock_class_set_accuracy() and bt_clock_class_get_accuracy() functions.
Having an unknown accuracy makes it possible to set the intended origin of a clock class while communicating that clock snapshots may not align with the true origin.
The origin property of a clock class, which is either unknown or the Unix epoch with MIP 0, can be custom.
A custom origin is a point on the real timeline which is the base of clock snapshots. The Unix epoch is just a renowned origin with its own dedicated functions in Babeltrace 2.
Snapshots of clocks having the same origin, whatever the other clock class properties, have a correlation.
A custom origin is identified by an optional namespace and a mandatory name/UID pair. Set the custom origin of a clock class with bt_clock_class_set_origin().
Make the origin the Unix epoch with bt_clock_class_set_origin_unix_epoch() or unknown with bt_clock_class_set_origin_unknown().
bt_clock_class_set_origin_is_unix_epoch() still works but is deprecated.
The clock class origin property getters are:
bt_clock_class_create() still sets the initial origin to the Unix epoch.
A bit array field class may have zero or more flags.
The bit array field class flag API is very similar to the unsigned enumeration field class mapping API.
A flag assigns a label to one or more bits, by indexes, of instances (bit array fields). When any of the bits of some flag is set (true) within a bit array field, said flag is known to be active.
The new related functions are:
bt_field_class_bit_array_get_active_flag_labels_for_value_as_integer()
An integer field class may have field value hints.
An integer field class field value hint is a marker that provides additional context about the expected characteristics of instance (integer field) values. These hints serve as non-binding recommendations to guide downstream components about specific properties or optimizations.
As of Babeltrace 2.0, the only available hint is BT_FIELD_CLASS_INTEGER_FIELD_VALUE_HINT_SMALL which means that instances of the integer field class are expected to hold small integer values.
The new related functions are:
A BLOB field class describes BLOB fields which contain zero or more bytes of binary data.
With MIP 0, you can use a string field class or an array field class with an 8-bit unsigned integer element field class as the class of some byte container. However, both have their limitations.
A BLOB field is the perfect container of pure binary data.
Like static and dynamic array field classes, you can create both static and dynamic BLOB field classes:
Is a BT_FIELD_CLASS_TYPE_BLOB and a BT_FIELD_CLASS_TYPE_STATIC_BLOB.
Is a BT_FIELD_CLASS_TYPE_BLOB, a BT_FIELD_CLASS_TYPE_DYNAMIC_BLOB, and a BT_FIELD_CLASS_TYPE_DYNAMIC_BLOB_WITHOUT_LENGTH_FIELD.
Is a BT_FIELD_CLASS_TYPE_BLOB, a BT_FIELD_CLASS_TYPE_DYNAMIC_BLOB, and a BT_FIELD_CLASS_TYPE_DYNAMIC_BLOB_WITH_LENGTH_FIELD.
This one accepts a field location: see the Field location API section below to learn more.
A BLOB field class has a media type property which the creation functions initialize to application/octet-stream
, a very generic one. The media type indicates which kind of data the instances hold.
Just like with a dynamic array field, set the length of a dynamic BLOB field with bt_field_blob_dynamic_set_length() before getting its internal buffer.
Get the length of a BLOB field with bt_field_blob_get_length().
Get the internal buffer of a BLOB field with:
Starting from MIP 1, the classes of all the fields with links to other fields use a field location to show the link instead of a field path.
A field location is different from a field path: it contains a list of structure field member names to follow from some root scope to reach the target field. This makes it possible, for example, for the length field of some dynamic field to be located within one or more distant option fields and/or variant fields.
See Field location procedure to learn the exact procedure to locate a field.
Whereas libbabeltrace2 creates field path objects for you when you provide the target field class at dependent field class creation time, you create a field location object yourself. This is because a dependent field class may target more than one field class.
The field location API is:
You provide the root scope and all the items (structure member names) to this function.
The new field class creation functions to use are:
The new field location borrowing functions are:
The following functions aren't available with MIP 1: