From: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
To: Jonathan Corbet <corbet@lwn.net>,
Mauro Carvalho Chehab <mchehab@kernel.org>
Cc: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
Shuah Khan <skhan@linuxfoundation.org>
Subject: [PATCH v2 00/13] kernel-doc improvements
Date: Fri, 6 Mar 2026 16:45:38 +0100 [thread overview]
Message-ID: <cover.1772810752.git.mchehab+huawei@kernel.org> (raw)
Hi Jon,
This patch kernel-doc improvements. On v2, I'm keeping just
the patches related to man pages generation.
The first patches on this series are focused mostly on .TH
(troff header) line, but, as a side effect, it also change
the name of man pages generated from DOC kernel-doc annotations.
At the previous state, those were overriden due to lots of
duplicated names.
The rationale for most of such changes is that modern troff/man
page specs say that .TH has up to 5 arguments,, as defined at [1]:
.TH topic section [footer-middle] [footer-inside] [header-middle]
[1] https://man7.org/linux/man-pages/man7/groff_man_style.7.html
Right now, Kernel uses 6 arguments, probably due to some legacy
man page definitions.
After double checking, modern man pages use this format:
.TH "{name}" {section} "{date}" "{modulename}" "{manual}"
Right now, man pages generation are messing up on how it encodes
each position at .TH, depending on the type of object it emits.
After this series, the definition is more consistent and file
output is better named.
It also fixes two issues at sphinx-build-wrapper related to how
it generate files names from the .TH header.
The last 4 patches on this series are new: they fix lots of issues
related to groff format: there, new lines continue the test from
previous pagragraph. This cause issues mainly on:
- tables;
- code blocks;
- lists
With the changes, the output now looks a lot better.
Please notice that the code there is not meant to fully implement
rst -> troff/groff conversion. Instead, it is meant to make the
output reasonable.
A more complete approach would be to use docutils or Sphinx
libraries, but that would likely require to also write a troff
output plugin, as the "man" builder is very limited. Also,
this could be problematic, as kernel-doc classes can be called
from Sphinx. I don't think we need that much complexity, as what
we mainly need is to avoid bad line grouping when generating
man pages.
This series should not affect HTML documentation. It only affect
man page generation and ManFormat output class.
Mauro Carvalho Chehab (13):
docs: sphinx-build-wrapper: better handle troff .TH markups
docs: sphinx-build-wrapper: don't allow "/" on file names
docs: kdoc_output: use a method to emit the .TH header
docs: kdoc_output: remove extra attribute on man .TH headers
docs: kdoc_output: use a single manual for everything
docs: kdoc_output: don't use a different modulename for functions
docs: kdoc_output: fix naming for DOC markups
docs: kdoc_output: describe the class init parameters
docs: kdoc_output: pick a better default for modulename
docs: kdoc_output: Change the logic to handle man highlight
docs: kdoc_output: add a logic to handle tables inside kernel-doc
markups
docs: kdoc_output: add support to handle code blocks
docs: kdoc_output: better handle lists
tools/docs/kernel-doc | 1 -
tools/docs/sphinx-build-wrapper | 10 +-
tools/lib/python/kdoc/kdoc_output.py | 297 +++++++++++++++++++++++++--
3 files changed, 283 insertions(+), 25 deletions(-)
--
2.52.0
next reply other threads:[~2026-03-06 15:45 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-06 15:45 Mauro Carvalho Chehab [this message]
2026-03-06 15:45 ` [PATCH v2 01/13] docs: sphinx-build-wrapper: better handle troff .TH markups Mauro Carvalho Chehab
2026-03-06 15:45 ` [PATCH v2 02/13] docs: sphinx-build-wrapper: don't allow "/" on file names Mauro Carvalho Chehab
2026-03-06 15:45 ` [PATCH v2 03/13] docs: kdoc_output: use a method to emit the .TH header Mauro Carvalho Chehab
2026-03-06 15:45 ` [PATCH v2 04/13] docs: kdoc_output: remove extra attribute on man .TH headers Mauro Carvalho Chehab
2026-03-06 15:45 ` [PATCH v2 05/13] docs: kdoc_output: use a single manual for everything Mauro Carvalho Chehab
2026-03-06 15:45 ` [PATCH v2 06/13] docs: kdoc_output: don't use a different modulename for functions Mauro Carvalho Chehab
2026-03-06 15:45 ` [PATCH v2 07/13] docs: kdoc_output: fix naming for DOC markups Mauro Carvalho Chehab
2026-03-06 15:45 ` [PATCH v2 08/13] docs: kdoc_output: describe the class init parameters Mauro Carvalho Chehab
2026-03-06 15:45 ` [PATCH v2 09/13] docs: kdoc_output: pick a better default for modulename Mauro Carvalho Chehab
2026-03-06 15:45 ` [PATCH v2 10/13] docs: kdoc_output: Change the logic to handle man highlight Mauro Carvalho Chehab
2026-03-06 15:45 ` [PATCH v2 11/13] docs: kdoc_output: add a logic to handle tables inside kernel-doc markups Mauro Carvalho Chehab
2026-03-06 15:45 ` [PATCH v2 12/13] docs: kdoc_output: add support to handle code blocks Mauro Carvalho Chehab
2026-03-06 15:45 ` [PATCH v2 13/13] docs: kdoc_output: better handle lists Mauro Carvalho Chehab
2026-03-09 16:39 ` [PATCH v2 00/13] kernel-doc improvements Jonathan Corbet
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=cover.1772810752.git.mchehab+huawei@kernel.org \
--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=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