public inbox for linux-next@vger.kernel.org
 help / color / mirror / Atom feed
From: Jonathan Corbet <corbet@lwn.net>
To: Chris Down <chris@chrisdown.name>,
	Stephen Rothwell <sfr@canb.auug.org.au>
Cc: linux-doc@vger.kernel.org, Petr Mladek <pmladek@suse.com>,
	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 printk tree
Date: Sun, 25 Jul 2021 15:16:00 -0600	[thread overview]
Message-ID: <87o8aqt7qn.fsf@meer.lwn.net> (raw)
In-Reply-To: <YPbABBSTkN+xNY0w@chrisdown.name>

Chris Down <chris@chrisdown.name> writes:

> Chris Down writes:
>>+Cc: Jonathan Corbet <corbet@lwn.net>, linux-doc@vger.kernel.org
>
> Well, let's actually Cc them this time...
>
>>Stephen Rothwell writes:
>>>After merging the printk tree, today's linux-next build (htmldocs)
>>>produced this warning:
>>>
>>>kernel/printk/printk.c:1: warning: 'printk' not found
>>>
>>>Introduced by commit
>>>
>>> 337015573718 ("printk: Userspace format indexing support")
>>>
>>>I presume that "printk" is referred to elsewhere in the documentation
>>>as being in this file.
>>
>>Hmm, this is an interesting one, because I think we still generally 
>>just want to refer to the API as being `printk()`. Changing it all 
>>over the place seems wrong. As you'd imagine, there are quite a few 
>>references to this name, so it requires a lot of noise all over the 
>>docs and inline comments.
>>
>>Jonathan and other docs folks, how can one tell Sphinx that when it 
>>sees printk() it's referring to a function-like macro, or otherwise 
>>squelch this reasonably? :-)

The problem is that you moved printk(), but left the associated
kerneldoc comment tied to _printk(), which isn't what you really want to
document.  The fix should look something like the attached.

Thanks,

jon

--------snip here----------------------
printk: Move the printk() kerneldoc comment to its new home

Commit 337015573718 ("printk: Userspace format indexing support") turned
printk() into a macro, but left the kerneldoc comment for it with the (now)
_printk() function, resulting in this docs-build warning:

  kernel/printk/printk.c:1: warning: 'printk' not found

Move the kerneldoc comment back next to the (now) macro it's meant to
describe and have the docs build find it there.

Signed-off-by: Jonathan Corbet <corbet@lwn.net>
---
 Documentation/core-api/printk-basics.rst |  5 +----
 include/linux/printk.h                   | 24 ++++++++++++++++++++++++
 kernel/printk/printk.c                   | 24 ------------------------
 3 files changed, 25 insertions(+), 28 deletions(-)

diff --git a/Documentation/core-api/printk-basics.rst b/Documentation/core-api/printk-basics.rst
index 965e4281eddd..2dde24ca7d9f 100644
--- a/Documentation/core-api/printk-basics.rst
+++ b/Documentation/core-api/printk-basics.rst
@@ -107,9 +107,6 @@ also ``CONFIG_DYNAMIC_DEBUG`` in the case of pr_debug()) is defined.
 Function reference
 ==================
 
-.. kernel-doc:: kernel/printk/printk.c
-   :functions: printk
-
 .. kernel-doc:: include/linux/printk.h
-   :functions: pr_emerg pr_alert pr_crit pr_err pr_warn pr_notice pr_info
+   :functions: printk pr_emerg pr_alert pr_crit pr_err pr_warn pr_notice pr_info
       pr_fmt pr_debug pr_devel pr_cont
diff --git a/include/linux/printk.h b/include/linux/printk.h
index 2651b82ed352..c1e176403967 100644
--- a/include/linux/printk.h
+++ b/include/linux/printk.h
@@ -431,6 +431,30 @@ struct pi_entry {
 	})
 
 
+/**
+ * printk - print a kernel message
+ * @fmt: format string
+ *
+ * This is printk(). It can be called from any context. We want it to work.
+ *
+ * If printk indexing is enabled, _printk() is called from printk_index_wrap.
+ * Otherwise, printk is simply #defined to _printk.
+ *
+ * We try to grab the console_lock. If we succeed, it's easy - we log the
+ * output and call the console drivers.  If we fail to get the semaphore, we
+ * place the output into the log buffer and return. The current holder of
+ * the console_sem will notice the new output in console_unlock(); and will
+ * send it to the consoles before releasing the lock.
+ *
+ * One effect of this deferred printing is that code which calls printk() and
+ * then changes console_loglevel may break. This is because console_loglevel
+ * is inspected when the actual printing occurs.
+ *
+ * See also:
+ * printf(3)
+ *
+ * See the vsnprintf() documentation for format string extensions over C99.
+ */
 #define printk(fmt, ...) printk_index_wrap(_printk, fmt, ##__VA_ARGS__)
 #define printk_deferred(fmt, ...)					\
 	printk_index_wrap(_printk_deferred, fmt, ##__VA_ARGS__)
diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
index 9b3bd6e017f1..63176be3b50c 100644
--- a/kernel/printk/printk.c
+++ b/kernel/printk/printk.c
@@ -2186,30 +2186,6 @@ int vprintk_default(const char *fmt, va_list args)
 }
 EXPORT_SYMBOL_GPL(vprintk_default);
 
-/**
- * _printk - print a kernel message
- * @fmt: format string
- *
- * This is _printk(). It can be called from any context. We want it to work.
- *
- * If printk indexing is enabled, _printk() is called from printk_index_wrap.
- * Otherwise, printk is simply #defined to _printk.
- *
- * We try to grab the console_lock. If we succeed, it's easy - we log the
- * output and call the console drivers.  If we fail to get the semaphore, we
- * place the output into the log buffer and return. The current holder of
- * the console_sem will notice the new output in console_unlock(); and will
- * send it to the consoles before releasing the lock.
- *
- * One effect of this deferred printing is that code which calls printk() and
- * then changes console_loglevel may break. This is because console_loglevel
- * is inspected when the actual printing occurs.
- *
- * See also:
- * printf(3)
- *
- * See the vsnprintf() documentation for format string extensions over C99.
- */
 asmlinkage __visible int _printk(const char *fmt, ...)
 {
 	va_list args;
-- 
2.31.1


  parent reply	other threads:[~2021-07-25 21:16 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-20  6:24 linux-next: build warning after merge of the printk tree Stephen Rothwell
2021-07-20 12:18 ` Chris Down
2021-07-20 12:22   ` Chris Down
2021-07-23 11:09     ` [PATCH] printk/documentation: Update printk()/_printk() documentation Petr Mladek
2021-07-23 11:24       ` Petr Mladek
2021-07-25 21:16     ` Jonathan Corbet [this message]
2021-07-26 12:28       ` linux-next: build warning after merge of the printk tree Petr Mladek
2021-07-26 13:07       ` Chris Down
  -- strict thread matches above, loose matches on Subject: below --
2022-11-22  7:10 Stephen Rothwell
     [not found] <CGME20180710064527epcas1p16fd9ad765711d69264b3251890bbcc2e@epcms5p5>
2018-07-10  6:45 ` Stephen Rothwell
2018-07-10  7:16   ` Maninder Singh
2018-07-10  9:19     ` Petr Mladek
2018-07-10 13:15       ` Sergey Senozhatsky

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=87o8aqt7qn.fsf@meer.lwn.net \
    --to=corbet@lwn.net \
    --cc=chris@chrisdown.name \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-next@vger.kernel.org \
    --cc=pmladek@suse.com \
    --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