trace doc: convert trace/tracepoints.txt to rst format
authorChangbin Du <changbin.du@intel.com>
Sat, 17 Feb 2018 05:39:41 +0000 (13:39 +0800)
committerJonathan Corbet <corbet@lwn.net>
Wed, 7 Mar 2018 17:23:23 +0000 (10:23 -0700)
This converts the plain text documentation to reStructuredText format and
add it into Sphinx TOC tree. No essential content change.

Cc: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Changbin Du <changbin.du@intel.com>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Documentation/trace/index.rst
Documentation/trace/tracepoints.rst [new file with mode: 0644]
Documentation/trace/tracepoints.txt [deleted file]

index 353fb8a91ab21ad1e44ef1c8161903fe21dc20e1..c8bbdfca52c5e7e4c3d65a3626c7b8745361159e 100644 (file)
@@ -11,3 +11,4 @@ Linux Tracing Technologies
    ftrace-uses
    kprobetrace
    uprobetracer
+   tracepoints
diff --git a/Documentation/trace/tracepoints.rst b/Documentation/trace/tracepoints.rst
new file mode 100644 (file)
index 0000000..6e3ce3b
--- /dev/null
@@ -0,0 +1,148 @@
+==================================
+Using the Linux Kernel Tracepoints
+==================================
+
+:Author: Mathieu Desnoyers
+
+
+This document introduces Linux Kernel Tracepoints and their use. It
+provides examples of how to insert tracepoints in the kernel and
+connect probe functions to them and provides some examples of probe
+functions.
+
+
+Purpose of tracepoints
+----------------------
+A tracepoint placed in code provides a hook to call a function (probe)
+that you can provide at runtime. A tracepoint can be "on" (a probe is
+connected to it) or "off" (no probe is attached). When a tracepoint is
+"off" it has no effect, except for adding a tiny time penalty
+(checking a condition for a branch) and space penalty (adding a few
+bytes for the function call at the end of the instrumented function
+and adds a data structure in a separate section).  When a tracepoint
+is "on", the function you provide is called each time the tracepoint
+is executed, in the execution context of the caller. When the function
+provided ends its execution, it returns to the caller (continuing from
+the tracepoint site).
+
+You can put tracepoints at important locations in the code. They are
+lightweight hooks that can pass an arbitrary number of parameters,
+which prototypes are described in a tracepoint declaration placed in a
+header file.
+
+They can be used for tracing and performance accounting.
+
+
+Usage
+-----
+Two elements are required for tracepoints :
+
+- A tracepoint definition, placed in a header file.
+- The tracepoint statement, in C code.
+
+In order to use tracepoints, you should include linux/tracepoint.h.
+
+In include/trace/events/subsys.h::
+
+       #undef TRACE_SYSTEM
+       #define TRACE_SYSTEM subsys
+
+       #if !defined(_TRACE_SUBSYS_H) || defined(TRACE_HEADER_MULTI_READ)
+       #define _TRACE_SUBSYS_H
+
+       #include <linux/tracepoint.h>
+
+       DECLARE_TRACE(subsys_eventname,
+               TP_PROTO(int firstarg, struct task_struct *p),
+               TP_ARGS(firstarg, p));
+
+       #endif /* _TRACE_SUBSYS_H */
+
+       /* This part must be outside protection */
+       #include <trace/define_trace.h>
+
+In subsys/file.c (where the tracing statement must be added)::
+
+       #include <trace/events/subsys.h>
+
+       #define CREATE_TRACE_POINTS
+       DEFINE_TRACE(subsys_eventname);
+
+       void somefct(void)
+       {
+               ...
+               trace_subsys_eventname(arg, task);
+               ...
+       }
+
+Where :
+  - subsys_eventname is an identifier unique to your event
+
+    - subsys is the name of your subsystem.
+    - eventname is the name of the event to trace.
+
+  - `TP_PROTO(int firstarg, struct task_struct *p)` is the prototype of the
+    function called by this tracepoint.
+
+  - `TP_ARGS(firstarg, p)` are the parameters names, same as found in the
+    prototype.
+
+  - if you use the header in multiple source files, `#define CREATE_TRACE_POINTS`
+    should appear only in one source file.
+
+Connecting a function (probe) to a tracepoint is done by providing a
+probe (function to call) for the specific tracepoint through
+register_trace_subsys_eventname().  Removing a probe is done through
+unregister_trace_subsys_eventname(); it will remove the probe.
+
+tracepoint_synchronize_unregister() must be called before the end of
+the module exit function to make sure there is no caller left using
+the probe. This, and the fact that preemption is disabled around the
+probe call, make sure that probe removal and module unload are safe.
+
+The tracepoint mechanism supports inserting multiple instances of the
+same tracepoint, but a single definition must be made of a given
+tracepoint name over all the kernel to make sure no type conflict will
+occur. Name mangling of the tracepoints is done using the prototypes
+to make sure typing is correct. Verification of probe type correctness
+is done at the registration site by the compiler. Tracepoints can be
+put in inline functions, inlined static functions, and unrolled loops
+as well as regular functions.
+
+The naming scheme "subsys_event" is suggested here as a convention
+intended to limit collisions. Tracepoint names are global to the
+kernel: they are considered as being the same whether they are in the
+core kernel image or in modules.
+
+If the tracepoint has to be used in kernel modules, an
+EXPORT_TRACEPOINT_SYMBOL_GPL() or EXPORT_TRACEPOINT_SYMBOL() can be
+used to export the defined tracepoints.
+
+If you need to do a bit of work for a tracepoint parameter, and
+that work is only used for the tracepoint, that work can be encapsulated
+within an if statement with the following::
+
+       if (trace_foo_bar_enabled()) {
+               int i;
+               int tot = 0;
+
+               for (i = 0; i < count; i++)
+                       tot += calculate_nuggets();
+
+               trace_foo_bar(tot);
+       }
+
+All trace_<tracepoint>() calls have a matching trace_<tracepoint>_enabled()
+function defined that returns true if the tracepoint is enabled and
+false otherwise. The trace_<tracepoint>() should always be within the
+block of the if (trace_<tracepoint>_enabled()) to prevent races between
+the tracepoint being enabled and the check being seen.
+
+The advantage of using the trace_<tracepoint>_enabled() is that it uses
+the static_key of the tracepoint to allow the if statement to be implemented
+with jump labels and avoid conditional branches.
+
+.. note:: The convenience macro TRACE_EVENT provides an alternative way to
+      define tracepoints. Check http://lwn.net/Articles/379903,
+      http://lwn.net/Articles/381064 and http://lwn.net/Articles/383362
+      for a series of articles with more details.
diff --git a/Documentation/trace/tracepoints.txt b/Documentation/trace/tracepoints.txt
deleted file mode 100644 (file)
index a3efac6..0000000
+++ /dev/null
@@ -1,145 +0,0 @@
-                    Using the Linux Kernel Tracepoints
-
-                           Mathieu Desnoyers
-
-
-This document introduces Linux Kernel Tracepoints and their use. It
-provides examples of how to insert tracepoints in the kernel and
-connect probe functions to them and provides some examples of probe
-functions.
-
-
-* Purpose of tracepoints
-
-A tracepoint placed in code provides a hook to call a function (probe)
-that you can provide at runtime. A tracepoint can be "on" (a probe is
-connected to it) or "off" (no probe is attached). When a tracepoint is
-"off" it has no effect, except for adding a tiny time penalty
-(checking a condition for a branch) and space penalty (adding a few
-bytes for the function call at the end of the instrumented function
-and adds a data structure in a separate section).  When a tracepoint
-is "on", the function you provide is called each time the tracepoint
-is executed, in the execution context of the caller. When the function
-provided ends its execution, it returns to the caller (continuing from
-the tracepoint site).
-
-You can put tracepoints at important locations in the code. They are
-lightweight hooks that can pass an arbitrary number of parameters,
-which prototypes are described in a tracepoint declaration placed in a
-header file.
-
-They can be used for tracing and performance accounting.
-
-
-* Usage
-
-Two elements are required for tracepoints :
-
-- A tracepoint definition, placed in a header file.
-- The tracepoint statement, in C code.
-
-In order to use tracepoints, you should include linux/tracepoint.h.
-
-In include/trace/events/subsys.h :
-
-#undef TRACE_SYSTEM
-#define TRACE_SYSTEM subsys
-
-#if !defined(_TRACE_SUBSYS_H) || defined(TRACE_HEADER_MULTI_READ)
-#define _TRACE_SUBSYS_H
-
-#include <linux/tracepoint.h>
-
-DECLARE_TRACE(subsys_eventname,
-       TP_PROTO(int firstarg, struct task_struct *p),
-       TP_ARGS(firstarg, p));
-
-#endif /* _TRACE_SUBSYS_H */
-
-/* This part must be outside protection */
-#include <trace/define_trace.h>
-
-In subsys/file.c (where the tracing statement must be added) :
-
-#include <trace/events/subsys.h>
-
-#define CREATE_TRACE_POINTS
-DEFINE_TRACE(subsys_eventname);
-
-void somefct(void)
-{
-       ...
-       trace_subsys_eventname(arg, task);
-       ...
-}
-
-Where :
-- subsys_eventname is an identifier unique to your event
-    - subsys is the name of your subsystem.
-    - eventname is the name of the event to trace.
-
-- TP_PROTO(int firstarg, struct task_struct *p) is the prototype of the
-  function called by this tracepoint.
-
-- TP_ARGS(firstarg, p) are the parameters names, same as found in the
-  prototype.
-
-- if you use the header in multiple source files, #define CREATE_TRACE_POINTS
-  should appear only in one source file.
-
-Connecting a function (probe) to a tracepoint is done by providing a
-probe (function to call) for the specific tracepoint through
-register_trace_subsys_eventname().  Removing a probe is done through
-unregister_trace_subsys_eventname(); it will remove the probe.
-
-tracepoint_synchronize_unregister() must be called before the end of
-the module exit function to make sure there is no caller left using
-the probe. This, and the fact that preemption is disabled around the
-probe call, make sure that probe removal and module unload are safe.
-
-The tracepoint mechanism supports inserting multiple instances of the
-same tracepoint, but a single definition must be made of a given
-tracepoint name over all the kernel to make sure no type conflict will
-occur. Name mangling of the tracepoints is done using the prototypes
-to make sure typing is correct. Verification of probe type correctness
-is done at the registration site by the compiler. Tracepoints can be
-put in inline functions, inlined static functions, and unrolled loops
-as well as regular functions.
-
-The naming scheme "subsys_event" is suggested here as a convention
-intended to limit collisions. Tracepoint names are global to the
-kernel: they are considered as being the same whether they are in the
-core kernel image or in modules.
-
-If the tracepoint has to be used in kernel modules, an
-EXPORT_TRACEPOINT_SYMBOL_GPL() or EXPORT_TRACEPOINT_SYMBOL() can be
-used to export the defined tracepoints.
-
-If you need to do a bit of work for a tracepoint parameter, and
-that work is only used for the tracepoint, that work can be encapsulated
-within an if statement with the following:
-
-       if (trace_foo_bar_enabled()) {
-               int i;
-               int tot = 0;
-
-               for (i = 0; i < count; i++)
-                       tot += calculate_nuggets();
-
-               trace_foo_bar(tot);
-       }
-
-All trace_<tracepoint>() calls have a matching trace_<tracepoint>_enabled()
-function defined that returns true if the tracepoint is enabled and
-false otherwise. The trace_<tracepoint>() should always be within the
-block of the if (trace_<tracepoint>_enabled()) to prevent races between
-the tracepoint being enabled and the check being seen.
-
-The advantage of using the trace_<tracepoint>_enabled() is that it uses
-the static_key of the tracepoint to allow the if statement to be implemented
-with jump labels and avoid conditional branches.
-
-Note: The convenience macro TRACE_EVENT provides an alternative way to
-      define tracepoints. Check http://lwn.net/Articles/379903,
-      http://lwn.net/Articles/381064 and http://lwn.net/Articles/383362
-      for a series of articles with more details.