Project

General

Profile

Actions

Feature #1300

open

babeltrace2 lacks knowledge of bitwise enum produced by lttng-modules

Added by Mathieu Desnoyers over 3 years ago. Updated about 1 month ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
-
Target version:
Start date:
03/23/2021
Due date:
% Done:

0%

Estimated time:

Description

This is a follow up on https://review.lttng.org/c/babeltrace/+/3045 now that end users are starting to contact us wondering why up-to-date lttng and babeltrace2 show incomplete information for bitwise enums.

I think we should implement a better stop-gap solution while awaiting CTF2. I recommend that we specialize the babeltrace2 CTF input plugin to detect traces produced by the lttng-modules kernel tracer, for specific known (hardcoded) events and fields which have a bitwise enum semantic, and use this hardcoded knowledge to print the correct bitwise enum to the end user rather than "<unknown>".

This should ensure the current producer/consumer tools work well together (show complete information about those bitwise enums) without requiring to modify tons of documentation about the specific flags needed for bt2 to handle lttng traces appropriately. And this would not lead to misleading scenarios where we print an unknown value as a bitwise enum by mistake.

Hardcoded producer detection/event/fields is of course a last resort solution awaiting proper self-description in the upcoming CTF2 spec.

Actions #1

Updated by Jérémie Galarneau over 3 years ago

  • Tracker changed from Bug to Feature
  • Target version changed from Babeltrace - stable 2.0 to Babeltrace - 2.1

Setting target version to 2.1 and setting as a feature request as it is not a bug.

Actions #2

Updated by Philippe Proulx about 1 month ago

Adding a note that CTF 2's fixed-length bit map field classes will take care of this (supported by the upcoming Babeltrace 2.1).

Actions

Also available in: Atom PDF