From: "Li Xinhai" <lixinhai.lxh@gmail.com>
To: "Tom Zanussi" <zanussi@kernel.org>,
"Steven Rostedt" <rostedt@goodmis.org>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] tracing: Fix events.rst section numbering
Date: Fri, 22 May 2020 10:09:42 +0800 [thread overview]
Message-ID: <2020052210094049322420@gmail.com> (raw)
In-Reply-To: 90ea854dfb728390b50ddf8a8675238973ee014a.camel@kernel.org
On 2020-05-19 at 02:29 Tom Zanussi wrote:
>The in-kernel trace event API should have its own section, and the
>duplicate section numbers need fixing as well.
>
>Signed-off-by: Tom Zanussi <zanussi@kernel.org>
>Reported-by: Li Xinhai <lixinhai.lxh@gmail.com>
>---
> Documentation/trace/events.rst | 28 ++++++++++++++--------------
> 1 file changed, 14 insertions(+), 14 deletions(-)
>
>diff --git a/Documentation/trace/events.rst b/Documentation/trace/events.rst
>index ed79b220bd07..1a3b7762cb0f 100644
>--- a/Documentation/trace/events.rst
>+++ b/Documentation/trace/events.rst
>@@ -526,8 +526,8 @@ The following commands are supported:
>
> See Documentation/trace/histogram.rst for details and examples.
>
>-6.3 In-kernel trace event API
>------------------------------
>+7. In-kernel trace event API
>+============================
>
> In most cases, the command-line interface to trace events is more than
> sufficient. Sometimes, however, applications might find the need for
>@@ -559,8 +559,8 @@ following:
> - tracing synthetic events from in-kernel code
> - the low-level "dynevent_cmd" API
>
>-6.3.1 Dyamically creating synthetic event definitions
>------------------------------------------------------
>+7.1 Dyamically creating synthetic event definitions
>+---------------------------------------------------
>
> There are a couple ways to create a new synthetic event from a kernel
> module or other kernel code.
>@@ -665,8 +665,8 @@ registered by calling the synth_event_gen_cmd_end() function:
> At this point, the event object is ready to be used for tracing new
> events.
>
>-6.3.3 Tracing synthetic events from in-kernel code
>---------------------------------------------------
>+7.2 Tracing synthetic events from in-kernel code
>+------------------------------------------------
>
> To trace a synthetic event, there are several options. The first
> option is to trace the event in one call, using synth_event_trace()
>@@ -677,8 +677,8 @@ synth_event_trace_start() and synth_event_trace_end() along with
> synth_event_add_next_val() or synth_event_add_val() to add the values
> piecewise.
>
>-6.3.3.1 Tracing a synthetic event all at once
>----------------------------------------------
>+7.2.1 Tracing a synthetic event all at once
>+-------------------------------------------
>
> To trace a synthetic event all at once, the synth_event_trace() or
> synth_event_trace_array() functions can be used.
>@@ -779,8 +779,8 @@ remove the event:
>
> ret = synth_event_delete("schedtest");
>
>-6.3.3.1 Tracing a synthetic event piecewise
>--------------------------------------------
>+7.2.2 Tracing a synthetic event piecewise
>+-----------------------------------------
>
> To trace a synthetic using the piecewise method described above, the
> synth_event_trace_start() function is used to 'open' the synthetic
>@@ -863,8 +863,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).
>
>-6.3.4 Dyamically creating kprobe and kretprobe event definitions
>-----------------------------------------------------------------
>+7.3 Dyamically 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()
>@@ -940,8 +940,8 @@ used to give the kprobe event file back and delete the event:
>
> ret = kprobe_event_delete("gen_kprobe_test");
>
>-6.3.4 The "dynevent_cmd" low-level API
>---------------------------------------
>+7.4 The "dynevent_cmd" low-level API
>+------------------------------------
>
> Both the in-kernel synthetic event and kprobe interfaces are built on
> top of a lower-level "dynevent_cmd" interface. This interface is
>--
>2.17.1
>
It looks correct to me.
Reviewed-by: Li Xinhai <lixinhai.lxh@gmail.com>
>
next prev parent reply other threads:[~2020-05-22 2:09 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-18 18:29 [PATCH] tracing: Fix events.rst section numbering Tom Zanussi
2020-05-22 2:09 ` Li Xinhai [this message]
2020-05-22 12:37 ` Steven Rostedt
2020-05-25 19:40 ` Jonathan Corbet
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2020052210094049322420@gmail.com \
--to=lixinhai.lxh@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=rostedt@goodmis.org \
--cc=zanussi@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.