[RFC][PATCH] tracing: Show available event triggers when no trigger is set

[Steven Rostedt]

Currently there's no way to know what triggers exist on a kernel without
looking at the source of the kernel or randomly trying out triggers.
Instead of creating another file in the debugfs system, simply show
what available triggers are there when cat'ing the trigger file when
it has no events:

[root /sys/kernel/debug/tracing]# cat events/sched/sched_switch/trigger
# Available triggers:
# disable_event enable_event stacktrace snapshot traceoff traceon

This stays consistent with other debugfs files where meta data like
this is always proceeded with a '#' at the start of the line so that
tools can strip these out.

Signed-off-by: Steven Rostedt <ros...@goodmis.org>
---
kernel/trace/trace_events_trigger.c | 20 ++++++++++++++++++++
1 file changed, 20 insertions(+)

diff --git a/kernel/trace/trace_events_trigger.c b/kernel/trace/trace_events_trigger.c
index a53e0da..90cf83c 100644
--- a/kernel/trace/trace_events_trigger.c
+++ b/kernel/trace/trace_events_trigger.c
@@ -115,10 +115,15 @@ event_triggers_post_call(struct ftrace_event_file *file,
}
EXPORT_SYMBOL_GPL(event_triggers_post_call);

+#define SHOW_AVAILABLE_TRIGGERS (void *)(1UL)
+
static void *trigger_next(struct seq_file *m, void *t, loff_t *pos)
{
struct ftrace_event_file *event_file = event_file_data(m->private);

+ if (t == SHOW_AVAILABLE_TRIGGERS)
+ return NULL;
+
return seq_list_next(t, &event_file->triggers, pos);
}

@@ -132,6 +137,9 @@ static void *trigger_start(struct seq_file *m, loff_t *pos)
if (unlikely(!event_file))
return ERR_PTR(-ENODEV);

+ if (list_empty(&event_file->triggers))
+ return *pos == 0 ? SHOW_AVAILABLE_TRIGGERS : NULL;
+
return seq_list_start(&event_file->triggers, *pos);
}

@@ -143,6 +151,18 @@ static void trigger_stop(struct seq_file *m, void *t)
static int trigger_show(struct seq_file *m, void *v)
{
struct event_trigger_data *data;
+ struct event_command *p;
+
+ if (v == SHOW_AVAILABLE_TRIGGERS) {
+ seq_puts(m, "# Available triggers:\n");
+ seq_putc(m, '#');
+ mutex_lock(&trigger_cmd_mutex);
+ list_for_each_entry(p, &trigger_commands, list)
+ seq_printf(m, " %s", p->name);
+ seq_putc(m, '\n');
+ mutex_unlock(&trigger_cmd_mutex);
+ return 0;
+ }

data = list_entry(v, struct event_trigger_data, list);
data->ops->print(m, data->ops, data);
--
1.8.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

[Tom Zanussi]

On Tue, 2014-01-07 at 10:35 -0500, Steven Rostedt wrote:
> Currently there's no way to know what triggers exist on a kernel without
> looking at the source of the kernel or randomly trying out triggers.
> Instead of creating another file in the debugfs system, simply show
> what available triggers are there when cat'ing the trigger file when
> it has no events:
>
> [root /sys/kernel/debug/tracing]# cat events/sched/sched_switch/trigger
> # Available triggers:
> # disable_event enable_event stacktrace snapshot traceoff traceon
>
> This stays consistent with other debugfs files where meta data like
> this is always proceeded with a '#' at the start of the line so that
> tools can strip these out.

Nice idea - very helpful and makes use of that 'unused space'. ;-)

Even better might be printing the full event formats and examples as in
tracing/README, but that would probably mean adding a new event-specific
description function to event_command, and it might get unwieldy with
too many events. Just a thought...

Tom

[Steven Rostedt]

On Tue, 07 Jan 2014 17:34:56 -0600
Tom Zanussi <tom.z...@linux.intel.com> wrote:


> Nice idea - very helpful and makes use of that 'unused space'. ;-)

I came up with it when I was writing my tests against the event
triggers, and didn't know what triggers I had, and realized there was
no easy way to figure it out.

>
> Even better might be printing the full event formats and examples as in
> tracing/README, but that would probably mean adding a new event-specific
> description function to event_command, and it might get unwieldy with
> too many events. Just a thought...

I had that same thought, but then thought against it. It would make
things too complicated, and that's what text documentation is for. Or
we can even add it to the tracing/README too.

-- Steve

[Namhyung Kim]

Hi Steve,

On Tue, 7 Jan 2014 10:35:48 -0500, Steven Rostedt wrote:
> Currently there's no way to know what triggers exist on a kernel without
> looking at the source of the kernel or randomly trying out triggers.
> Instead of creating another file in the debugfs system, simply show
> what available triggers are there when cat'ing the trigger file when
> it has no events:
>
> [root /sys/kernel/debug/tracing]# cat events/sched/sched_switch/trigger
> # Available triggers:
> # disable_event enable_event stacktrace snapshot traceoff traceon
>
> This stays consistent with other debugfs files where meta data like
> this is always proceeded with a '#' at the start of the line so that
> tools can strip these out.

[SNIP]

> + if (v == SHOW_AVAILABLE_TRIGGERS) {
> + seq_puts(m, "# Available triggers:\n");
> + seq_putc(m, '#');
> + mutex_lock(&trigger_cmd_mutex);
> + list_for_each_entry(p, &trigger_commands, list)

I guess the list_for_each_entry_reverse() will give a more intuitive
result here:

[root /sys/kernel/debug/tracing]# cat events/sched/sched_switch/trigger
# Available triggers:

# traceon traceoff snapshot stacktrace enable_event disable_event

Thanks,
Namhyung

> + seq_printf(m, " %s", p->name);
> + seq_putc(m, '\n');
> + mutex_unlock(&trigger_cmd_mutex);
> + return 0;
> + }
>
> data = list_entry(v, struct event_trigger_data, list);
> data->ops->print(m, data->ops, data);
--

[Steven Rostedt]

On Wed, 08 Jan 2014 16:50:47 +0900
Namhyung Kim <namh...@kernel.org> wrote:

> [SNIP]
> > + if (v == SHOW_AVAILABLE_TRIGGERS) {
> > + seq_puts(m, "# Available triggers:\n");
> > + seq_putc(m, '#');
> > + mutex_lock(&trigger_cmd_mutex);
> > + list_for_each_entry(p, &trigger_commands, list)
>
> I guess the list_for_each_entry_reverse() will give a more intuitive
> result here:
>
> [root /sys/kernel/debug/tracing]# cat events/sched/sched_switch/trigger
> # Available triggers:
> # traceon traceoff snapshot stacktrace enable_event disable_event
>

Updated. Thanks for the review.

-- Steve