From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: Jonathan Corbet <corbet@lwn.net>,
ksummit-discuss@lists.linuxfoundation.org,
ksummit@lists.linux.dev
Subject: Re: [TECH TOPIC] What kernel documentation could be
Date: Sat, 25 Jun 2022 20:48:55 +0300 [thread overview]
Message-ID: <YrdKhw8gww20ODYr@pendragon.ideasonboard.com> (raw)
In-Reply-To: <20220625134328.19b5356c@rorschach.local.home>
Hi Steven,
On Sat, Jun 25, 2022 at 01:43:28PM -0400, Steven Rostedt wrote:
> On Fri, 17 Jun 2022 14:57:10 -0600 Jonathan Corbet wrote:
>
> > The development community has put a lot of work into the kernel's
> > documentation directory in recent years, with visible results. But the
> > kernel's documentation still falls far short of the standard set by many
> > other projects, and there is a great deal of "tribal knowledge" in our
> > community that is not set down. I'd like to look at the successes and
> > failures of the work so far, but intent to focus on a discussion of what
> > our documentation should be and what we can do to get it there.
> >
> > Questions to discuss include:
> >
> > - Bringing an coherent overall structure to Documentation/
> >
> > - Making it easier for developers to improve the documentation.
>
> Is there a way to mark comments in the code as "design docs". And I
> don't mean the kernel-doc that is already above functions.
>
> I have lots of comments about the design of complex code just above the
> code it is describing. Which is much more likely to get updated when
> the design changes or gets new features.
>
> I found my design documents I have under Documentation to become
> grossly obsolete over time, where as the comments above the code I can
> keep up with.
>
> Is there already some kind of mark up that we can add to the comments to state:
>
> ** .design.trace/ftrace.rst .ringbuffer. **
>
> or something that can be extracted into another document? With the
> above example, I could have in Documentatino/trace/ftrace.rst a
>
> .design .ringbuffer.
>
> And the comment from the code would be extracted into the html
> documents that are created?
>
> Or maybe it would be better to reference the code from the documentation?
>
> .include kerne/trace/ring_buffer.c .ringbuffer.
>
> That will look for a tag in kernel/trace/ring_buffer.c called
> ".ringbuffer" and pull in the comment into the document under Documentation.
>
> Thoughts?
See the "DOC: overview" block in drivers/gpu/drm/drm_atomic_helper.c,
and how it is integrated in Documentation/gpu/drm-kms-helpers.rst with
.. kernel-doc:: drivers/gpu/drm/drm_atomic_helper.c
:doc: overview
Is that what you're looking for ?
> > - What we would like from Sphinx and what we can do to make it happen
> >
> > - Making the docs build system less ugly and more maintainable
> >
> > - Integrating rustdoc documentation
--
Regards,
Laurent Pinchart
prev parent reply other threads:[~2022-06-25 17:49 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-17 20:57 [TECH TOPIC] What kernel documentation could be Jonathan Corbet
2022-06-17 20:57 ` [Ksummit-discuss] " Jonathan Corbet
2022-06-17 21:48 ` Laurent Pinchart
2022-06-17 21:48 ` Laurent Pinchart
2022-06-27 15:18 ` Jonathan Corbet
2022-06-18 8:24 ` Mauro Carvalho Chehab
2022-06-18 8:24 ` Mauro Carvalho Chehab
2022-06-18 11:03 ` Miguel Ojeda
2022-06-18 11:16 ` Mauro Carvalho Chehab
2022-06-18 11:16 ` Mauro Carvalho Chehab
2022-06-18 14:37 ` Miguel Ojeda
2022-06-23 9:18 ` Jani Nikula
2022-06-23 9:57 ` Mauro Carvalho Chehab
2022-06-23 10:30 ` Jani Nikula
2022-06-23 13:40 ` Jonathan Corbet
2022-06-24 7:33 ` Mauro Carvalho Chehab
2022-06-24 16:37 ` Markus Heiser
2022-06-27 15:27 ` Jonathan Corbet
2022-06-27 15:31 ` Christoph Hellwig
2022-06-28 7:43 ` Mauro Carvalho Chehab
2022-06-28 7:57 ` Geert Uytterhoeven
2022-06-28 11:01 ` Mauro Carvalho Chehab
2022-07-02 12:43 ` Stephen Rothwell
2022-06-24 22:57 ` Jonathan Corbet
2022-06-25 9:10 ` Mauro Carvalho Chehab
2022-06-25 14:00 ` Jonathan Corbet
2022-06-25 18:11 ` Linus Torvalds
2022-06-26 7:55 ` Mauro Carvalho Chehab
2022-06-26 9:26 ` Mauro Carvalho Chehab
2022-06-26 9:53 ` Mauro Carvalho Chehab
2022-06-27 15:28 ` Liam Howlett
2022-06-27 15:54 ` Christian Brauner
2022-06-27 16:27 ` Mark Brown
2022-06-28 10:53 ` Mauro Carvalho Chehab
2022-06-28 16:13 ` Luck, Tony
2022-06-27 15:34 ` Jonathan Corbet
2022-06-27 17:07 ` Linus Torvalds
2022-07-02 10:52 ` Mauro Carvalho Chehab
2022-06-25 17:43 ` Steven Rostedt
2022-06-25 17:48 ` Laurent Pinchart [this message]
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=YrdKhw8gww20ODYr@pendragon.ideasonboard.com \
--to=laurent.pinchart@ideasonboard.com \
--cc=corbet@lwn.net \
--cc=ksummit-discuss@lists.linuxfoundation.org \
--cc=ksummit@lists.linux.dev \
--cc=rostedt@goodmis.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).