linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Steven Rostedt <rostedt@goodmis.org>
To: Jonathan Corbet <corbet@lwn.net>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>,
	linux-doc@vger.kernel.org,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Linux Next Mailing List <linux-next@vger.kernel.org>
Subject: Re: linux-next: build warning after merge of the ftrace tree
Date: Mon, 16 Nov 2020 15:25:52 -0500	[thread overview]
Message-ID: <20201116152552.11572354@gandalf.local.home> (raw)
In-Reply-To: <20201116122432.796af13b@lwn.net>

On Mon, 16 Nov 2020 12:24:32 -0700
Jonathan Corbet <corbet@lwn.net> wrote:

> The problem is those literal blocks.  The easiest fix will be to just use
> the double-colon notation to indicate a literal block, so the paragraph
> above would end with "...start your code with::".  Note that there's a few
> of them to fix.

Would something like the below work? I think I fixed the other places with
issues and for consistency, replaced the ".. code-block:: c" with just "::"
usage throughout the file.

-- Steve

diff --git a/Documentation/trace/ftrace-uses.rst b/Documentation/trace/ftrace-uses.rst
index 5981d5691745..f21464538fa0 100644
--- a/Documentation/trace/ftrace-uses.rst
+++ b/Documentation/trace/ftrace-uses.rst
@@ -43,9 +43,7 @@ as well as what protections the callback will perform and not require
 ftrace to handle.
 
 There is only one field that is needed to be set when registering
-an ftrace_ops with ftrace:
-
-.. code-block:: c
+an ftrace_ops with ftrace::
 
  struct ftrace_ops ops = {
        .func			= my_callback_func,
@@ -82,9 +80,7 @@ may take some time to finish.
 The callback function
 =====================
 
-The prototype of the callback function is as follows (as of v4.14):
-
-.. code-block:: c
+The prototype of the callback function is as follows (as of v4.14)::
 
    void callback_func(unsigned long ip, unsigned long parent_ip,
                       struct ftrace_ops *op, struct pt_regs *regs);
@@ -114,7 +110,7 @@ Protect your callback
 As functions can be called from anywhere, and it is possible that a function
 called by a callback may also be traced, and call that same callback,
 recursion protection must be used. There are two helper functions that
-can help in this regard. If you start your code with:
+can help in this regard. If you start your code with::
 
 	int bit;
 
@@ -122,7 +118,7 @@ can help in this regard. If you start your code with:
 	if (bit < 0)
 		return;
 
-and end it with:
+and end it with::
 
 	ftrace_test_recursion_unlock(bit);
 
@@ -143,7 +139,7 @@ function call.
 If your callback accesses any data or critical section that requires RCU
 protection, it is best to make sure that RCU is "watching", otherwise
 that data or critical section will not be protected as expected. In this
-case add:
+case add::
 
 	if (!rcu_is_watching())
 		return;
@@ -249,9 +245,7 @@ match a specific pattern.
 
 See Filter Commands in :file:`Documentation/trace/ftrace.rst`.
 
-To just trace the schedule function:
-
-.. code-block:: c
+To just trace the schedule function::
 
    ret = ftrace_set_filter(&ops, "schedule", strlen("schedule"), 0);
 
@@ -259,17 +253,13 @@ To add more functions, call the ftrace_set_filter() more than once with the
 @reset parameter set to zero. To remove the current filter set and replace it
 with new functions defined by @buf, have @reset be non-zero.
 
-To remove all the filtered functions and trace all functions:
-
-.. code-block:: c
+To remove all the filtered functions and trace all functions::
 
    ret = ftrace_set_filter(&ops, NULL, 0, 1);
 
 
 Sometimes more than one function has the same name. To trace just a specific
-function in this case, ftrace_set_filter_ip() can be used.
-
-.. code-block:: c
+function in this case, ftrace_set_filter_ip() can be used::
 
    ret = ftrace_set_filter_ip(&ops, ip, 0, 0);
 
@@ -284,9 +274,7 @@ two lists are non-empty and contain the same functions, the callback will not
 be called by any function.
 
 An empty "notrace" list means to allow all functions defined by the filter
-to be traced.
-
-.. code-block:: c
+to be traced::
 
    int ftrace_set_notrace(struct ftrace_ops *ops, unsigned char *buf,
                           int len, int reset);
@@ -298,9 +286,7 @@ filter list, and this function does not modify the filter list.
 A non-zero @reset will clear the "notrace" list before adding functions
 that match @buf to it.
 
-Clearing the "notrace" list is the same as clearing the filter list
-
-.. code-block:: c
+Clearing the "notrace" list is the same as clearing the filter list::
 
   ret = ftrace_set_notrace(&ops, NULL, 0, 1);
 
@@ -311,9 +297,7 @@ has been registered.
 
 If a filter is in place, and the @reset is non-zero, and @buf contains a
 matching glob to functions, the switch will happen during the time of
-the ftrace_set_filter() call. At no time will all functions call the callback.
-
-.. code-block:: c
+the ftrace_set_filter() call. At no time will all functions call the callback::
 
    ftrace_set_filter(&ops, "schedule", strlen("schedule"), 1);
 
@@ -323,9 +307,7 @@ the ftrace_set_filter() call. At no time will all functions call the callback.
 
    ftrace_set_filter(&ops, "try_to_wake_up", strlen("try_to_wake_up"), 1);
 
-is not the same as:
-
-.. code-block:: c
+is not the same as::
 
    ftrace_set_filter(&ops, "schedule", strlen("schedule"), 1);
 

  reply	other threads:[~2020-11-16 20:26 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-16  6:35 linux-next: build warning after merge of the ftrace tree Stephen Rothwell
2020-11-16 17:43 ` Steven Rostedt
2020-11-16 19:24   ` Jonathan Corbet
2020-11-16 20:25     ` Steven Rostedt [this message]
2020-11-16 20:29       ` Jonathan Corbet
2020-11-16 20:35         ` Steven Rostedt
2020-11-18 15:35         ` [PATCH] ftrace/documentation: Fix RST C code blocks Steven Rostedt
2020-11-18 15:51           ` Steven Rostedt
2020-11-18 16:24             ` Jonathan Corbet
2020-11-18 16:26               ` Steven Rostedt
2020-11-18 16:28                 ` Jonathan Corbet
2020-11-18 16:44                   ` Steven Rostedt
  -- strict thread matches above, loose matches on Subject: below --
2023-06-23  4:35 linux-next: build warning after merge of the ftrace tree Stephen Rothwell
2023-06-23  6:53 ` Donglin Peng
2022-11-25  3:10 Stephen Rothwell
2021-10-28 12:23 Stephen Rothwell
2021-10-28 13:16 ` Steven Rostedt
2021-10-28 21:10   ` Stephen Rothwell
2021-10-28 21:29     ` Kalesh Singh
2021-10-28 22:36       ` Stephen Rothwell
2021-10-28 21:30     ` Steven Rostedt
2021-10-25 23:35 Stephen Rothwell
2021-10-26 12:15 ` Masami Hiramatsu
2021-10-25  4:39 Stephen Rothwell
2021-10-25  6:13 ` Masami Hiramatsu
2021-08-23  9:58 Stephen Rothwell
2021-08-23 14:00 ` Steven Rostedt
2021-08-24 10:53   ` Stephen Rothwell
2020-08-05  4:21 Stephen Rothwell
2019-11-15  3:02 Stephen Rothwell
2019-11-15  3:43 ` Steven Rostedt
2014-06-04  6:09 Stephen Rothwell
2014-06-04 16:26 ` Steven Rostedt
2014-06-04 16:49   ` Stephen Rothwell
2014-06-05  0:20   ` Fengguang Wu
2014-06-05  1:00     ` Steven Rostedt
2014-06-05  1:03       ` Fengguang Wu
2014-06-05  1:12         ` Steven Rostedt
2014-06-05  1:20           ` Steven Rostedt
2014-06-05  1:33           ` Fengguang Wu
2014-06-05  1:39             ` Steven Rostedt
2014-06-05  2:14               ` Fengguang Wu
2014-06-05  2:36                 ` Steven Rostedt
2014-06-05  2:50                   ` Fengguang Wu
2014-06-05  3:03                   ` Fengguang Wu
2014-06-05  3:13                     ` Steven Rostedt
2014-06-05  3:42                       ` Fengguang Wu
2014-06-05  2:38                 ` Steven Rostedt
2014-06-05  2:44                   ` Fengguang Wu
2014-06-05  2:46                 ` Steven Rostedt

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=20201116152552.11572354@gandalf.local.home \
    --to=rostedt@goodmis.org \
    --cc=corbet@lwn.net \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-next@vger.kernel.org \
    --cc=sfr@canb.auug.org.au \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).