linux-xfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Akira Yokosawa <akiyks@gmail.com>
To: hch@lst.de
Cc: chandanbabu@kernel.org, corbet@lwn.net, david@fromorbit.com,
	djwong@kernel.org, linux-kernel@vger.kernel.org,
	linux-next@vger.kernel.org, linux-xfs@vger.kernel.org,
	mchehab@kernel.org, sfr@canb.auug.org.au,
	Akira Yokosawa <akiyks@gmail.com>
Subject: Re: linux-next: build warning after merge of the xfs tree
Date: Sat, 24 Feb 2024 18:07:28 +0900	[thread overview]
Message-ID: <22187737-e0ad-4cc4-98fd-5e43ebc5ecee@gmail.com> (raw)
In-Reply-To: <20240223140619.GA30519@lst.de>

Hi,

On Fri, 23 Feb 2024 15:06:19 +0100, Christoph Hellwig wrote:
> On Fri, Feb 23, 2024 at 09:55:09AM +0100, Mauro Carvalho Chehab wrote:
>> but it is very weird for the ones reading the text file. So, what
>> we do instead for pointers is to escape the entire declaration, like:
>> 
>> 	``*inode``
>> 	``struct inode *inode``
>> 
>> I hope that helps.
> 
> In this case it says *foliop for an argument that is a double pointer
> and the comment refers to what it point to.  I'll see what I can do
> there, but the whole italic and bold thing seems entirely pointless
> for kerneldoc..

Indeed.

How about teaching kernel-doc unary "*" on param?

Substitution would look like:

   (kernel-doc)       (RST)
   *@param     ->  ***param**

Sphinx detects double asterisk, starts strong emphasis, waits for
another double asterisk to appear, and stops strong emphasis.
Hence you would get boldface "*param" in pretty printed docs.

Diff below (against docs-next) should add a rule for param_deref
(only for RST).

diff --git a/scripts/kernel-doc b/scripts/kernel-doc
index 136104804375..bdd6f3b489cc 100755
--- a/scripts/kernel-doc
+++ b/scripts/kernel-doc
@@ -65,7 +65,7 @@ my $type_constant = '\b``([^\`]+)``\b';
 my $type_constant2 = '\%([-_\*\w]+)';
 my $type_func = '(\w+)\(\)';
 my $type_param = '\@(\w*((\.\w+)|(->\w+))*(\.\.\.)?)';
-my $type_param_ref = '([\!~]?)\@(\w*((\.\w+)|(->\w+))*(\.\.\.)?)';
+my $type_param_ref = '([\!~\*]?)\@(\w*((\.\w+)|(->\w+))*(\.\.\.)?)';
 my $type_fp_param = '\@(\w+)\(\)';  # Special RST handling for func ptr params
 my $type_fp_param2 = '\@(\w+->\S+)\(\)';  # Special RST handling for structs with func ptr params
 my $type_env = '(\$\w+)';
-- 

And you would be able to write the kernel-doc comment in question
as follows:

diff --git a/mm/shmem.c b/mm/shmem.c
index 750ab1dcae27..0aad0d9a621b 100644
--- a/mm/shmem.c
+++ b/mm/shmem.c
@@ -2152,8 +2152,8 @@ static int shmem_get_folio_gfp(struct inode *inode, pgoff_t index,
  * There is no need to reserve space before calling folio_mark_dirty().
  *
  * When no folio is found, the behavior depends on @sgp:
- *  - for SGP_READ, *foliop is %NULL and 0 is returned
- *  - for SGP_NOALLOC, *foliop is %NULL and -ENOENT is returned
+ *  - for SGP_READ, *@foliop is %NULL and 0 is returned
+ *  - for SGP_NOALLOC, *@foliop is %NULL and -ENOENT is returned
  *  - for all other flags a new folio is allocated, inserted into the
  *    page cache and returned locked in @foliop.
  *
-- 

How does this approach sound to you? 

        Thanks, Akira


  reply	other threads:[~2024-02-24  9:07 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-23  4:36 linux-next: build warning after merge of the xfs tree Stephen Rothwell
2024-02-23  6:35 ` Christoph Hellwig
2024-02-23  8:55   ` Mauro Carvalho Chehab
2024-02-23 14:06     ` Christoph Hellwig
2024-02-24  9:07       ` Akira Yokosawa [this message]
2024-02-26 10:57         ` Christoph Hellwig
     [not found] <D20pUU7kdgWfIpAYmLR776cP2sU4_NhTrc4Fasx5DbMewO7J6UW6QX_81athF3DSSPP2tZiEZNid_Rlin4p6lw==@protonmail.internalid>
2025-09-08  8:04 ` Stephen Rothwell
2025-09-16 10:22   ` Carlos Maiolino
     [not found] <95VzqAdwXL6uADPxQWGQV9LD2OtK9bUX7if_opYIYTcdIroqe7176LhnAst-sIYFTfU2tgwJknumIwzvYvxyTQ==@protonmail.internalid>
2025-04-22 10:25 ` Stephen Rothwell
2025-04-22 10:46   ` Carlos Maiolino
2025-04-22 11:38     ` Hans Holmberg
  -- strict thread matches above, loose matches on Subject: below --
2021-06-07  0:48 Stephen Rothwell
2021-06-07  1:15 ` Dave Chinner
2021-02-08 12:44 Stephen Rothwell
2021-01-24 22:55 Stephen Rothwell
2021-01-25 13:26 ` Brian Foster
2021-01-27  3:14   ` Darrick J. Wong
2020-05-08  1:15 Stephen Rothwell
2020-01-16  0:37 Stephen Rothwell
2020-01-15 22:12 Stephen Rothwell
2020-01-24  2:47 ` Stephen Rothwell
2020-01-24  4:17   ` Darrick J. Wong
2017-10-31 22:42 Stephen Rothwell
2017-08-31  0:07 Stephen Rothwell
2017-08-31 10:30 ` Brian Foster
2017-08-31 14:57   ` Darrick J. Wong
2017-08-31 15:22     ` Brian Foster
2017-08-31 15:41       ` Darrick J. Wong
2017-08-31 21:32       ` Dave Chinner

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=22187737-e0ad-4cc4-98fd-5e43ebc5ecee@gmail.com \
    --to=akiyks@gmail.com \
    --cc=chandanbabu@kernel.org \
    --cc=corbet@lwn.net \
    --cc=david@fromorbit.com \
    --cc=djwong@kernel.org \
    --cc=hch@lst.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-next@vger.kernel.org \
    --cc=linux-xfs@vger.kernel.org \
    --cc=mchehab@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).