Lines Matching +full:trigger +full:- +full:name
24 ---------------------------------
36 To disable an event, echo the event name to the set_event file prefixed
50 etc., and a full event name looks like this: <subsystem>:<event>. The
51 subsystem name is optional, but it is displayed in the available_events
59 ---------------------------
82 - 0 - all events this file affects are disabled
83 - 1 - all events this file affects are enabled
84 - X - there is a mixture of events enabled and disabled
85 - ? - this file does not affect any event
88 ---------------
92 trace_event=[event-list]
94 event-list is a comma separated list of events. See section 2.1 for event
97 3. Defining an event-enabled tracepoint
111 event in text mode, along with the event name and ID used for
121 field:field-type field-name; offset:N; size:N;
131 name: sched_wakeup
146 print fmt: "task %s:%d [%d] success=%d [%03d]", REC->comm, REC->pid,
147 REC->prio, REC->success, REC->cpu
150 event-specific. All the fields for this event are numeric, except for
166 ---------------------
174 field-name relational-operator value
177 double-quotes can be used to prevent the shell from interpreting
180 The field-names available for use in filters can be found in the
183 The relational-operators depend on the type of the field being tested:
203 field name::
210 You can convert any long type to a function address and search by function name::
223 a user-provided cpumask in cpulist format. The format is as follows::
234 target_cpu & CPUS{17-42}
237 -------------------
258 -bash: echo: write error: Invalid argument
269 ------------------------
279 --------------------
288 ---------------------
323 Attempt to set a filter using a non-common field for all events in the
335 -----------------
357 Trace events can be made to conditionally invoke trigger 'commands'
361 with attached triggers is invoked, the set of trigger commands
362 associated with that event is invoked. Any given trigger can
364 section 5 (Event filtering) associated with it - the command will only
366 If no filter is associated with the trigger, it always passes.
369 trigger expressions to the 'trigger' file for the given event.
393 /sys/kernel/tracing/events/ftrace/print/trigger
396 ---------------------
398 Triggers are added by echoing the command to the 'trigger' file::
400 # echo 'command[:count] [if filter]' > trigger
403 to the 'trigger' file::
405 # echo '!command[:count] [if filter]' > trigger
414 For ease of use, writing to the trigger file using '>' currently just
415 adds or removes a single trigger and there's no explicit '>>' support
419 6.2 Supported trigger commands
420 ------------------------------
424 - enable_event/disable_event
430 The event tracepoint stays in this mode as long as there's a trigger
431 in effect that can trigger it.
433 For example, the following trigger causes kmalloc events to be
438 /sys/kernel/tracing/events/syscalls/sys_enter_read/trigger
440 The following trigger causes kmalloc events to stop being traced
445 /sys/kernel/tracing/events/syscalls/sys_exit_read/trigger
455 /sys/kernel/tracing/events/syscalls/sys_enter_read/trigger
458 /sys/kernel/tracing/events/syscalls/sys_exit_read/trigger
461 per triggering event, but there can only be one trigger per
468 - stacktrace
473 For example, the following trigger dumps a stacktrace every time the
477 /sys/kernel/tracing/events/kmem/kmalloc/trigger
479 The following trigger dumps a stacktrace the first 5 times a kmalloc
483 /sys/kernel/tracing/events/kmem/kmalloc/trigger
492 /sys/kernel/tracing/events/kmem/kmalloc/trigger
495 /sys/kernel/tracing/events/kmem/kmalloc/trigger
501 /sys/kernel/tracing/events/kmem/kmalloc/trigger
503 Note that there can be only one stacktrace trigger per triggering
506 - snapshot
514 capture those events when the trigger event occurred::
517 /sys/kernel/tracing/events/block/block_unplug/trigger
522 /sys/kernel/tracing/events/block/block_unplug/trigger
527 /sys/kernel/tracing/events/block/block_unplug/trigger
530 /sys/kernel/tracing/events/block/block_unplug/trigger
532 Note that there can be only one snapshot trigger per triggering
535 - traceon/traceoff
545 trigger event::
548 /sys/kernel/tracing/events/block/block_unplug/trigger
553 /sys/kernel/tracing/events/block/block_unplug/trigger
558 /sys/kernel/tracing/events/block/block_unplug/trigger
561 /sys/kernel/tracing/events/block/block_unplug/trigger
563 Note that there can be only one traceon or traceoff trigger per
566 - hist
575 7. In-kernel trace event API
578 In most cases, the command-line interface to trace events is more than
581 series of linked command-line expressions, or putting together sets of
584 maintain an in-kernel state machine detecting, for instance, when an
587 The trace event subsystem provides an in-kernel API allowing modules
588 or other kernel code to generate user-defined 'synthetic' events at
592 A similar in-kernel API is also available for creating kprobe and
596 of a lower-level "dynevent_cmd" event command API, which is also
598 higher-level trace event APIs.
603 - dynamically creating synthetic event definitions
604 - dynamically creating kprobe and kretprobe event definitions
605 - tracing synthetic events from in-kernel code
606 - the low-level "dynevent_cmd" API
609 ---------------------------------------------------
615 In this method, the name of the event to create and an array defining
617 synthetic event with that name and fields will exist following that
625 name::
628 { .type = "pid_t", .name = "next_pid_field" },
629 { .type = "char[16]", .name = "next_comm_field" },
630 { .type = "u64", .name = "ts_ns" },
631 { .type = "u64", .name = "ts_ms" },
632 { .type = "unsigned int", .name = "cpu" },
633 { .type = "char[64]", .name = "my_string_field" },
634 { .type = "int", .name = "my_int_field" },
647 in-kernel API described below can't be used with dynamic arrays. The
648 other non-piecewise in-kernel APIs can, however, be used with dynamic
666 the name of the event along with one or more pairs of args each pair
668 supplied. For synth_event_gen_cmd_array_start(), the name of the
699 type, and a field name. For example, to add a new int field named
714 synth_event_add_field_str() can be used to add it as-is; it will
725 7.2 Tracing synthetic events from in-kernel code
726 ------------------------------------------------
732 need for a pre-formed array of values or list of arguments, via
738 -------------------------------------------
745 trace_get_event_file() using the synthetic event name, "synthetic" as
746 the system name, and the trace instance name (NULL if using the global
769 trace_get_event_file() using the synthetic event name, "synthetic" as
770 the system name, and the trace instance name (NULL if using the global
797 it - it will find the file in the given trace instance (in this case
809 the "synthetic" system name to be specified explicitly).
813 trace_array_set_clr_event(schedtest_event_file->tr,
818 trace_array_set_clr_event(schedtest_event_file->tr,
830 trace_array_set_clr_event(schedtest_event_file->tr,
840 -----------------------------------------
858 the event, which requires no lookups, or by name, which does. The
869 this method would be (without error-handling code)::
894 the synth_event_trace_start(), along with the field name of the field
896 the above examples using this method would be (without error-handling
910 incompatible if used within the same trace of an event - either one
920 of whether any of the add calls failed (say due to a bad field name
924 --------------------------------------------------------------
931 should first be created using kprobe_event_gen_cmd_start(). The name
979 kretprobe_event_gen_cmd_start() with a probe name and location and
990 ret = trace_array_set_clr_event(gen_kprobe_test->tr,
1000 7.4 The "dynevent_cmd" low-level API
1001 ------------------------------------
1003 Both the in-kernel synthetic event and kprobe interfaces are built on
1004 top of a lower-level "dynevent_cmd" interface. This interface is
1005 meant to provide the basis for higher-level interfaces such as the
1008 The basic idea is simple and amounts to providing a general-purpose
1010 generated command strings can then be passed to the command-parsing
1014 In a nutshell, the way it works is that the higher-level interface
1034 The dynevent_cmd initialization needs to be given a user-specified
1036 for this purpose - at 2k it's generally too big to be comfortably put
1039 correct command type, and a pointer to an event-specific run_command()
1040 callback that will be called to actually execute the event-specific
1044 calls to argument-adding functions.
1049 a whitespace-separated argument to the command::
1055 arg.str = name;
1061 optional sanity-checking function or separator appended to the end of
1074 arg_pair.rhs = name;
1085 add a string as-is, with no spaces, delimiters, or arg check.
1088 (until its length surpasses cmd->maxlen). When all the arguments have