linux-doc.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jonathan Corbet <corbet@lwn.net>
To: Matthew Wilcox <willy@infradead.org>
Cc: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>,
	Linux Doc Mailing List <linux-doc@vger.kernel.org>,
	Rob Herring <robh@kernel.org>,
	linux-kernel@vger.kernel.org,
	Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
Subject: Re: kerneldoc and rust (was [PATCH] kernel-doc: better handle '::' sequences)
Date: Mon, 29 Mar 2021 13:34:14 -0600	[thread overview]
Message-ID: <87czvhrbyh.fsf@meer.lwn.net> (raw)
In-Reply-To: <20210329144204.GF351017@casper.infradead.org>

Matthew Wilcox <willy@infradead.org> writes:

If we're going to talk about incorporating Rust into the doc system, we
should probably include some Rust folks - thus, I'm adding Miguel.

> On Thu, Mar 25, 2021 at 04:30:32PM -0600, Jonathan Corbet wrote:
>> Matthew Wilcox <willy@infradead.org> writes:
>> 
>> We did come to the mutual agreement that teaching kernel-doc to parse
>> Rust code as well was not an ideal solution.  Probably there will be
>> some sort of tool to translate between rustdoc and our sphinx setup.
>> Beyond that, we'll see how it goes.
>
> In the spirit of groping around for the best solution, I did some looking
> around at various options, including using rustdoc for .c files (that
> uses Markdown, which appears to be strictly worse than rST for our
> purposes).
>
> So here's my "modest proposal":
>
>  - Similar to our ".. kernel-doc::" invocation in .rst files, handle
>    ".. rustdoc::" (insert weeks of hacking here)
>  - Now add ".. rst-doc::" which parses .c files like [1] kernel-doc
>    does, but interprets a different style of comment and actually does
>    most of the repetitive boring bits for you.
>
> For example, xa_load:
>
> /**
>  * xa_load() - Load an entry from an XArray.
>  * @xa: XArray.
>  * @index: index into array.
>  *
>  * Context: Any context.  Takes and releases the RCU lock.
>  * Return: The entry at @index in @xa.
>  */
> void *xa_load(struct xarray *xa, unsigned long index)
>
> //rST
> // Load an entry from an XArray.
> //
> // :Context: Any context.  Takes and releases the RCU lock.
> // :Return: The entry in `xa` at `index`.
> void *xa_load(struct xarray *xa, unsigned long index)
>
> (more complex example below [2])
>
> Things I considered:
>
>  - Explicitly document that this is rST markup instead of Markdown or
>    whatever.
>  - Don't repeat the name of the function.  The tool can figure it out.

That worries me a wee bit just because a common source of problems is
kerneldoc comments becoming separated from the functions they describe
over time.  We finally have tooling to notice that; this seems like a
step in the other direction.

>  - Don't force documenting each parameter.  Often they are obvious
>    and there's really nothing interesting to say about the parameter.
>    Witness the number of '@foo: The foo' (of type struct foo) that we
>    have scattered throughout the tree.  It's not that the documenter is
>    lazy, it's that there's genuinely nothing to say here.

...another failure mode is developers adding parameters and not
documenting them; this would mask that problem too.

>  - Use `interpreted text` to refer to parameters instead of *emphasis* or
>    **strong emphasis**.  The tool can turn that into whatever markup
>    is appropriate.
>  - Use field lists for Context and Return instead of sections.  The markup
>    is simpler to use, and I think the rendered output is better.
>
> [1] by which i mean "in a completely different way from, but similar in
>     concept"
>
> [2] More complex example:
>
> /**
>  * xa_store() - Store this entry in the XArray.
>  * @xa: XArray.
>  * @index: Index into array.
>  * @entry: New entry.
>  * @gfp: Memory allocation flags.
>  *
>  * After this function returns, loads from this index will return @entry.
>  * Storing into an existing multi-index entry updates the entry of every index.
>  * The marks associated with @index are unaffected unless @entry is %NULL.
>  *
>  * Context: Any context.  Takes and releases the xa_lock.
>  * May sleep if the @gfp flags permit.
>  * Return: The old entry at this index on success, xa_err(-EINVAL) if @entry
>  * cannot be stored in an XArray, or xa_err(-ENOMEM) if memory allocation
>  * failed.
>  */
> void *xa_store(struct xarray *xa, unsigned long index, void *entry, gfp_t gfp)
>
> //rST
> // Store an entry in the XArray.
> //
> // After this function returns, loads from `index` will return `entry`.
> // Storing into an existing multi-index entry updates the entry of every index.
> // The marks associated with `index` are unaffected unless `entry` is ``NULL``.
> //
> // :Context: Any context.  Takes and releases the xa_lock.
> //    May sleep if the `gfp` flags permit.
> // :Return: The old entry at this index on success, xa_err(-EINVAL) if `entry`
> //    cannot be stored in an XArray, or xa_err(-ENOMEM) if memory allocation
> //    failed.
> void *xa_store(struct xarray *xa, unsigned long index, void *entry, gfp_t gfp)

Thanks,

jon

  parent reply	other threads:[~2021-03-29 19:34 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-25 16:47 [PATCH 0/8] dt: doc build improvements and kerneldoc addition Rob Herring
2021-03-25 16:47 ` [PATCH 1/8] dt-bindings: Fix reference in submitting-patches.rst to the DT ABI doc Rob Herring
2021-03-25 17:51   ` Mauro Carvalho Chehab
2021-03-25 16:47 ` [PATCH 2/8] docs: dt: writing-schema: Remove spurious indentation Rob Herring
2021-03-25 17:51   ` Mauro Carvalho Chehab
2021-03-25 16:47 ` [PATCH 3/8] docs: dt: writing-schema: Include the example schema in the doc build Rob Herring
2021-03-25 17:52   ` Mauro Carvalho Chehab
2021-03-25 16:47 ` [PATCH 4/8] docs: dt: Make 'Devicetree' wording more consistent Rob Herring
2021-03-25 17:25   ` Mauro Carvalho Chehab
2021-03-25 16:47 ` [PATCH 5/8] docs: dt: Group DT docs into relevant sub-sections Rob Herring
2021-03-25 17:52   ` Mauro Carvalho Chehab
2021-03-25 16:47 ` [PATCH 6/8] of: Fix kerneldoc output formatting Rob Herring
2021-03-25 17:46   ` Mauro Carvalho Chehab
2021-03-25 18:14     ` [PATCH] kernel-doc: better handle '::' sequences Mauro Carvalho Chehab
2021-03-25 18:51       ` Jonathan Corbet
2021-03-25 19:14         ` Matthew Wilcox
2021-03-25 21:04           ` Jonathan Corbet
2021-03-25 22:14             ` Matthew Wilcox
2021-03-25 22:30               ` Jonathan Corbet
2021-03-29 14:42                 ` Matthew Wilcox
2021-03-29 18:33                   ` Jani Nikula
2021-03-29 18:58                     ` Matthew Wilcox
2021-03-30 11:35                       ` Jani Nikula
2021-03-30 12:43                         ` Markus Heiser
2021-03-30 13:06                           ` Matthew Wilcox
2021-03-29 19:34                   ` Jonathan Corbet [this message]
2021-03-29 19:42                     ` kerneldoc and rust (was [PATCH] kernel-doc: better handle '::' sequences) Miguel Ojeda
2021-03-29 20:40               ` [PATCH] kernel-doc: better handle '::' sequences Miguel Ojeda
2021-03-30 11:07                 ` Jani Nikula
2021-03-30 22:46                   ` Miguel Ojeda
2021-03-25 16:47 ` [PATCH 7/8] of: Add missing 'Return' section in kerneldoc comments Rob Herring
2021-03-25 17:52   ` Mauro Carvalho Chehab
2021-03-25 16:47 ` [PATCH 8/8] docs: dt: Add DT API documentation Rob Herring
2021-03-25 17:53   ` Mauro Carvalho Chehab

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=87czvhrbyh.fsf@meer.lwn.net \
    --to=corbet@lwn.net \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mchehab+huawei@kernel.org \
    --cc=miguel.ojeda.sandonis@gmail.com \
    --cc=robh@kernel.org \
    --cc=willy@infradead.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 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).