diff options
Diffstat (limited to 'Documentation/trace/events.rst')
| -rw-r--r-- | Documentation/trace/events.rst | 52 |
1 files changed, 45 insertions, 7 deletions
diff --git a/Documentation/trace/events.rst b/Documentation/trace/events.rst index f5fcb8e1218f..18d112963dec 100644 --- a/Documentation/trace/events.rst +++ b/Documentation/trace/events.rst @@ -55,6 +55,30 @@ command:: # echo 'irq:*' > /sys/kernel/tracing/set_event +The set_event file may also be used to enable events associated to only +a specific module:: + + # echo ':mod:<module>' > /sys/kernel/tracing/set_event + +Will enable all events in the module ``<module>``. If the module is not yet +loaded, the string will be saved and when a module is that matches ``<module>`` +is loaded, then it will apply the enabling of events then. + +The text before ``:mod:`` will be parsed to specify specific events that the +module creates:: + + # echo '<match>:mod:<module>' > /sys/kernel/tracing/set_event + +The above will enable any system or event that ``<match>`` matches. If +``<match>`` is ``"*"`` then it will match all events. + +To enable only a specific event within a system:: + + # echo '<system>:<event>:mod:<module>' > /sys/kernel/tracing/set_event + +If ``<event>`` is ``"*"`` then it will match all events within the system +for a given module. + 2.2 Via the 'enable' toggle --------------------------- @@ -219,6 +243,20 @@ the function "security_prepare_creds" and less than the end of that function. The ".function" postfix can only be attached to values of size long, and can only be compared with "==" or "!=". +Cpumask fields or scalar fields that encode a CPU number can be filtered using +a user-provided cpumask in cpulist format. The format is as follows:: + + CPUS{$cpulist} + +Operators available to cpumask filtering are: + +& (intersection), ==, != + +For example, this will filter events that have their .target_cpu field present +in the given cpumask:: + + target_cpu & CPUS{17-42} + 5.2 Setting filters ------------------- @@ -591,8 +629,8 @@ following: - tracing synthetic events from in-kernel code - the low-level "dynevent_cmd" API -7.1 Dyamically creating synthetic event definitions ---------------------------------------------------- +7.1 Dynamically creating synthetic event definitions +---------------------------------------------------- There are a couple ways to create a new synthetic event from a kernel module or other kernel code. @@ -906,8 +944,8 @@ Note that synth_event_trace_end() must be called at the end regardless of whether any of the add calls failed (say due to a bad field name being passed in). -7.3 Dyamically creating kprobe and kretprobe event definitions --------------------------------------------------------------- +7.3 Dynamically creating kprobe and kretprobe event definitions +--------------------------------------------------------------- To create a kprobe or kretprobe trace event from kernel code, the kprobe_event_gen_cmd_start() or kretprobe_event_gen_cmd_start() @@ -915,7 +953,7 @@ functions can be used. To create a kprobe event, an empty or partially empty kprobe event should first be created using kprobe_event_gen_cmd_start(). The name -of the event and the probe location should be specfied along with one +of the event and the probe location should be specified along with one or args each representing a probe field should be supplied to this function. Before calling kprobe_event_gen_cmd_start(), the user should create and initialize a dynevent_cmd object using @@ -995,7 +1033,7 @@ The basic idea is simple and amounts to providing a general-purpose layer that can be used to generate trace event commands. The generated command strings can then be passed to the command-parsing and event creation code that already exists in the trace event -subystem for creating the corresponding trace events. +subsystem for creating the corresponding trace events. In a nutshell, the way it works is that the higher-level interface code creates a struct dynevent_cmd object, then uses a couple @@ -1068,7 +1106,7 @@ to add an operator between the pair (here none) and a separator to be appended onto the end of the arg pair (here ';'). There's also a dynevent_str_add() function that can be used to simply -add a string as-is, with no spaces, delimeters, or arg check. +add a string as-is, with no spaces, delimiters, or arg check. Any number of dynevent_*_add() calls can be made to build up the string (until its length surpasses cmd->maxlen). When all the arguments have |