Feature #445
openlttng enable-event and event redefinition: user feedback can be misleading
0%
Description
Here is an abridged log that outlines the problem:
$ sudo -H lttng create asession Session asession created. Traces will be written in /root/lttng-traces/asession-20130214-134634 $ sudo -H lttng list asession Tracing session asession: [inactive] Trace path: /root/lttng-traces/asession-20130214-134634 $ sudo -H lttng enable-event sched_switch -k --tracepoint kernel event sched_switch created in channel channel0 $ sudo -H lttng list asession Tracing session asession: [inactive] [...] Events: sched_switch (loglevel: TRACE_EMERG (0)) (type: tracepoint) [enabled] $ sudo -H lttng disable-event sched_switch -k kernel event sched_switch disabled in channel channel0 for session asession $ sudo -H lttng list asession Tracing session asession: [inactive] [...] Events: sched_switch (loglevel: TRACE_EMERG (0)) (type: tracepoint) [disabled] $ sudo -H lttng enable-event sched_switch -k --function lttng_calibrate_kretprobe kernel event sched_switch created in channel channel0 $ sudo -H lttng list asession Tracing session asession: [inactive] [...] Events: sched_switch (loglevel: TRACE_EMERG (0)) (type: tracepoint) [enabled]
The problem is that when the user tries to redefine an event by issuing enable-event again, if the event is enabled he gets LTTNG_ERR_KERN_EVENT_EXIST "Kernel event already exists"
, but if it is disabled, he gets no error and apparent confirmation ("kernel event sched_switch created in channel channel0"
). This can be misleading.
It seems the intent is that an event, once defined, is immutable. In that case, any redefinition attempt should yield LTTNG_ERR_KERN_EVENT_EXIST
, whether the event is currently enabled or not. Having a dual-use command "enable-event
" that acts upon a number of its options only when the event is first defined, while ignoring them when the event is merely re-enabled, is confusing for the user (it also makes the code unwieldy).
My suggestion is that event definition be split off into its own command, "define-event
", while restricting "enable-event
" to enabling already-defined events only. The corresponding --help
could be something like this (abridged):
usage: lttng define-event [NAME (-k|-u)] [OPTIONS] Options: -h, --help Show this help and exit --list-options List the options and exit -s, --session NAME Apply to session NAME -k, --kernel Apply to the kernel tracer -u, --userspace Apply to the userspace tracer -c, --channel NAME Apply to channel NAME Event options: --tracepoint Tracepoint event (default) --probe [addr | symbol | symbol+offset] Dynamic probe. Kernel only. Addr and offset can be octal (0NNN...), decimal (NNN...) or hexadecimal (0xNNN...) --function [addr | symbol | symbol+offset] Dynamic function entry/return probe. Kernel only. --syscall System call event. Kernel only. --loglevel NAME Tracepoint loglevel range from 0 to NAME. Userspace only. --loglevel-only NAME Tracepoint loglevel (only NAME) Userspace only. --filter 'expression' Filter expression on event fields, event recording depends on evaluation. Userspace only. usage: lttng enable-event [[NAME[,NAME2,...]] (-k|-u)] [OPTIONS] NAME can be omitted when using -a, --all. The userspace tracer supports wildcards at the end of the NAME strings for tracepoints. Don't forget to quote to deal with bash expansion. e.g.: "*", "app_component:na*" Options: -h, --help Show this help and exit --list-options List the options and exit -s, --session NAME Apply to session NAME -k, --kernel Apply to the kernel tracer -u, --userspace Apply to the user-space tracer -c, --channel NAME Apply to channel NAME -a, --all [TYPE] Enable all events If TYPE is specified, enable all events of the TYPE; TYPE can be tracepoint, syscall, probe, or function
Some features of the current enable-event could be kept in the new enable-event: for instance, an event could have its loglevel or filter settings adjusted (assuming this is possible now or in the future). Note how event definition now accepts a single event name to avoid bug #444.
Updated by David Goulet over 11 years ago
- Status changed from New to Confirmed
Indeed there can be a confusion here but we can't change the behavior of "enable-event" during the 2.x cycle since it will simply break the API.
However, to keep in mind for the 3.x release cycle because this is relevant to the user experience. An other idea would be to use "object" as the second level of lttng and not "action" such as:
$ lttng event --create ...
$ lttng event --disable ...
$ lttng event --enable
I can't do nothing for sure until we are out of 2.x
Thanks!
Updated by Christian Babeux over 11 years ago
- Tracker changed from Bug to Feature