Documentation/trace/events.rst

24 ---------------------------------
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
52 file.  All of the events in a subsystem can be specified via the syntax
53 ``<subsystem>:*``; for example, to enable all irq events, you can use the
59 ---------------------------
72 To enable all events in sched subsystem::
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
121      field:field-type field-name; offset:N; size:N;
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:
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 --------------------
284 To clear the filters for all events in a subsystem, write a '0' to the
285 subsystem's filter file.
287 5.4 Subsystem filters
288 ---------------------
290 For convenience, filters for every event in a subsystem can be set or
292 at the root of the subsystem.  Note however, that if a filter for any
293 event within the subsystem lacks a field specified in the subsystem
301 Here are a few subsystem filter examples that also illustrate the
304 Clear the filters on all events in the sched subsystem::
314 subsystem (all events end up with the same filter)::
323 Attempt to set a filter using a non-common field for all events in the
324 sched subsystem (all events but those that have a prev_pid field retain
335 -----------------
364 section 5 (Event filtering) associated with it - the command will only
396 ---------------------
420 ------------------------------
424 - enable_event/disable_event
468 - stacktrace
506 - snapshot
535 - traceon/traceoff
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 ---------------------------------------------------
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
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 -------------------------------------------
797 it - it will find the file in the given trace instance (in this case
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 -----------------------------------------
869 this method would be (without error-handling code)::
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
924 --------------------------------------------------------------
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
1012 subsystem for creating the corresponding trace events.
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::
1061 optional sanity-checking function or separator appended to the end of
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