From: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
To: Jonathan Corbet <corbet@lwn.net>
Cc: Linux Doc Mailing List <linux-doc@vger.kernel.org>,
linux-kernel@vger.kernel.org,
Mauro Carvalho Chehab <mchehab@kernel.org>,
Randy Dunlap <rdunlap@infradead.org>,
Shuah Khan <skhan@linuxfoundation.org>
Subject: Re: [PATCH RFC] docs: add python module documentation
Date: Wed, 14 Jan 2026 09:43:28 +0100 [thread overview]
Message-ID: <20260114094328.28f1a157@foz.lan> (raw)
In-Reply-To: <87wm1lw89g.fsf@trenco.lwn.net>
Em Tue, 13 Jan 2026 13:46:35 -0700
Jonathan Corbet <corbet@lwn.net> escreveu:
> Mauro Carvalho Chehab <mchehab+huawei@kernel.org> writes:
>
> > Hi Jon,
> >
> > While checking/improving docstrings inside kernel-doc, I noticed
> > that some changes there aren't Sphinx-compatible. Also, there are
> > several functions and some classes that miss documentation.
> >
> > Being responsible for doing some documentation work, I felt blamed
> > on not having a good documentation of our own dog food :-)
> >
> > So, I'm adding kdoc documentation to the Kernel documentation. The basic
> > change is just a couple of extra lines at conf.py, plus a few *.rst files
> > pointing to the files we want to document:
>
> At a first glance, this looks like a worthy task.
>
> I've never really played with autodoc.
once enabled, it is easy to add documentation. To document an entire
module, all we need is to add:
.. automodule:: kdoc.kdoc_files
:members:
:show-inheritance:
:undoc-members:
undoc-members mean to show functions and vars that don't have
any comments. IMHO we want that, as it will help checking what parts
are missing docs. There are ways to exclude parts of the document from
the docs (I'm not planning to use them).
So, at the ReST, we need to add an automodule for each new file there.
> Sure you don't want to fix up kernel-doc to read Python code too? :)
:-D
> Seriously, though, I worry that
> it could end up cluttering the code with a bunch of sphinxstuff, but the
> only way to really see is to try it.
Most of the documentation is extracted from standard python docstrings,
which will be handled as ReST. If you look at the patch, you'll see
that most of the changes are related to the lack of docstrings
(which also satifies linters, like pylint):
def get(self, key, default = None):
+ """Get a value from optional keys"""
return self.other_stuff.get(key, default)
Sphinx has the special "#:" syntax for comments that we want to
be at the documentation. So:
# output mode.
- OUTPUT_ALL = 0 # output all symbols and doc sections
- OUTPUT_INCLUDE = 1 # output only specified symbols
- OUTPUT_EXPORTED = 2 # output exported symbols
- OUTPUT_INTERNAL = 3 # output non-exported symbols
+ OUTPUT_ALL = 0 #: output all symbols and doc sections
+ OUTPUT_INCLUDE = 1 #: output only specified symbols
+ OUTPUT_EXPORTED = 2 #: output exported symbols
+ OUTPUT_INTERNAL = 3 #: output non-exported symbols
and:
+ #: Highlights to be used in ReST format
highlights = [
Add documentation to variables. Sphinx is smart enough to preserve
such comments on inherited classes, so, no need to document the same
functions 3 times for base, man and rest at kdoc_output.py.
So far, IMHO, all such changes will ensure that we'll have a good
documentation for python scripts.
Going further:
Documenting class instances will use the default representation,
which may not be the best. Adding a __repr__() allows adjusting
it (*):
+ def __repr__(self):
+ return f're.compile("{self.regex.pattern}")'
+
With that, all documentation for KernRe() will use it. For instance,
sphinx_cblock is documented as:
sphinx_cblock = re.compile("^\.\.\ +code-block::")
Sphinx code block regex
(*) I opted to use re.compile() instead of KernRe() because it
was simpler and more intuitive for people just looking at the
docs. We may, instead use KernRe() and then check if:
- flags != 0
- cache != True
and then output it as:
KernRe("pattern")
KernRe("pattern", cache=False)
KernRe("pattern", flags=Re.I)
but IMO just printing the pattern is enough for doc purpose.
On this patch, the only sphinxstuff are the usage of "#:"
and one Sphinx-specific notation here:
-!!! Caution !!!
+.. caution::
Thanks,
Mauro
prev parent reply other threads:[~2026-01-14 8:43 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-13 17:33 [PATCH RFC] docs: add python module documentation Mauro Carvalho Chehab
2026-01-13 20:46 ` Jonathan Corbet
2026-01-14 8:43 ` Mauro Carvalho Chehab [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=20260114094328.28f1a157@foz.lan \
--to=mchehab+huawei@kernel.org \
--cc=corbet@lwn.net \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mchehab@kernel.org \
--cc=rdunlap@infradead.org \
--cc=skhan@linuxfoundation.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