Bug #628
closedloglevel and loglevel-only filtering are indistinguishable from the console
100%
Description
Currently (lttng-tools-2.3.0-rc3-1-3e618c7), the lttng enable-event --loglevel and lttng enable-event --loglevel-only commands return the same confirmation message, and the lttng list session_name command displays both filtering schemes in exactly the same way. For example:
$ lttng create abcd
Session abcd created.
Traces will be written in /home/daniel/lttng-traces/abcd-20130906-104317
$ lttng enable-event -u -a --loglevel wArNiNg
All UST events are enabled in channel channel0 for loglevel wArNiNg
$ lttng start
Tracing started for session abcd
$ lttng list abcd
Tracing session abcd: [active]
Trace path: /home/daniel/lttng-traces/abcd-20130906-104317
=== Domain: UST global ===
Buffer type: per UID
Channels:
-------------
- channel0: [enabled]
Attributes:
overwrite mode: 0
subbufers size: 131072
number of subbufers: 4
switch timer interval: 0
read timer interval: 0
output: mmap()
Events:
* (loglevel: TRACE_WARNING (4)) (type: tracepoint) [enabled]
$ lttng destroy
Session abcd destroyed
$ lttng create abcde
Session abcde created.
Traces will be written in /home/daniel/lttng-traces/abcde-20130906-104720
$ lttng enable-event -u -a --loglevel-only NotiCE
All UST events are enabled in channel channel0 for loglevel NotiCE
$ lttng start
Tracing started for session abcde
$ lttng list abcde
Tracing session abcde: [active]
Trace path: /home/daniel/lttng-traces/abcde-20130906-104720
=== Domain: UST global ===
Buffer type: per UID
Channels:
-------------
- channel0: [enabled]
Attributes:
overwrite mode: 0
subbufers size: 131072
number of subbufers: 4
switch timer interval: 0
read timer interval: 0
output: mmap()
Events:
* (loglevel: TRACE_NOTICE (5)) (type: tracepoint) [enabled]
$ lttng destroy
Session abcde destroyed
The user should be able to tell the two cases apart. This can be achieved by changing the lttng enable-event --loglevel feedback slightly to something like:
$ lttng enable-event -u -a --loglevel wArNiNg All UST events are enabled in channel channel0 for loglevels up to wArNiNg
(It would also be nice if the message used the actual recognised loglevel constant name instead of the user's input: [...] for loglevels up to TRACE_WARNING (4))
Second, lttng list should make the distinction clear:
$ lttng list abcd
Tracing session abcd: [active]
[...]
Events:
* (loglevel <= TRACE_WARNING (4)) (type: tracepoint) [enabled]
$ lttng list abcde
Tracing session abcde: [active]
[...]
Events:
* (loglevel == TRACE_NOTICE (5)) (type: tracepoint) [enabled]
Updated by David Goulet almost 11 years ago
- Target version deleted (
2.3)
This is unfortunately a missing field from UST. I've opened a bug in the lttng-ust tracker linked to that issue. I'll keep this one open so we still have a trace that we need to do that in tools but I'll remove the target version for now.
Updated by David Goulet over 10 years ago
- Status changed from Confirmed to Resolved
- % Done changed from 0 to 100
Applied in changeset 1f0e17de5dc2c936acb87fde4fe92be546f03500.
Updated by Matthew Khouzam over 10 years ago
This breaks backwards compatibility, would it be possible to only display this when a flag like -IDONTKNOWWHATTHEFLAGSHOULDBE is passed?
Updated by Mathieu Desnoyers over 10 years ago
Matthew: this "breakage" fixes the user output between 2.3 and 2.4. This kind of change has to be expected. We're dealing about output to the end-user, and our release policies give us all rights to change this between two minor versions. We keep it compatible only within the patchlevel releases of a minor version (e.g. 2.3.0 vs 2.3.1).
The proper approach from a remote client perspective (like TMF) is to use a machine interface to interact with lttng-tools (work in progress on the lttng-tools side).
Meanwhile, I recommend that if your tools still need to parse the user output, you will need to query the lttng tools version (e.g. first line of lttng --help) and make version-specific adaptations based on the minor version.
Thanks,
Mathieu