From: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
To: Jonathan Corbet <corbet@lwn.net>
Cc: Karl Mehltretter <kmehltretter@gmail.com>,
Mauro Carvalho Chehab <mchehab@kernel.org>,
Shuah Khan <skhan@linuxfoundation.org>,
Randy Dunlap <rdunlap@infradead.org>,
Jakub Kicinski <kuba@kernel.org>,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3] docs: kerneldoc.py: preserve headings in kernel-doc output
Date: Wed, 14 Oct 2026 23:46:13 +0200 [thread overview]
Message-ID: <20261014233956.605e0960@foz.lan> (raw)
In-Reply-To: <8733u8w6p4.fsf@trenco.lwn.net>
On Wed, 14 Oct 2026 11:08:39 -0600
Jonathan Corbet <corbet@lwn.net> wrote:
> Karl Mehltretter <kmehltretter@gmail.com> writes:
>
> > kerneldoc.py parses extracted ReST into a detached section node while
> > retaining the surrounding title hierarchy. Docutils 0.21.2 silently drops
> > affected sections; 0.22.4 reports:
> >
> > Documentation/networking/kapi:107:
> > ../include/net/net_shaper.h:75:
> > ERROR: A level 3 section cannot be used here.
The backward-compatible fix is to ensure that the title markups will
be used on a consistent way, e.g., if:
- level 1 uses "====\n" + title + "\n===="
- level 2 uses "===="
- level 3 uses "----"
- level 4 uses "^^^^"
at the main doc, the kernel-doc tags shall follow the same schema,
e.g. if they are included at level 3, it has to use the level 4
markup.
So, in the specific case of kapi.rst, you can't use "====" nor
"----" inside net_shaper.h, as those are level 2 and level 3.
so, it has to use, for instance, "^^^^".
Yet, it is hard to make this on a consistent way and keep it
maintainable. The best is not use titles inside kernel-doc.
> >
> > The same issue drops three Xe DRM RAS headings already in mainline.
> >
> > Use nested_parse_with_titles() to give kernel-doc output an independent
> > title hierarchy.
> >
> > Fixes: 2404dad1f67f ("doc: Cope with the deprecation of AutoReporter")
> > Acked-by: Randy Dunlap <rdunlap@infradead.org>
> > Tested-by: Randy Dunlap <rdunlap@infradead.org>
> > Assisted-by: LLM
> > Signed-off-by: Karl Mehltretter <kmehltretter@gmail.com>
> > ---
> > Reposted as a standalone documentation patch at Jakub's suggestion:
> > https://lore.kernel.org/r/20260925120152.09ef180c@kernel.org/
> >
> > Changes since v2:
> > - Route the patch to the documentation maintainers without a net-next tag.
> > - Add Randy's Acked-by and Tested-by tags. No code changes.
>
> Which versions of Sphinx and docutils have you tested this with? I
> needs to work across the full range of supported versions...
The minimal docutils supported is 0.16, and the minimal Sphinx
supported version is 3.4.4.
You can use /tools/docs/test_doc_build.py to double check if your change
is compatible with the minimal supported Sphinx/docutils versions.
Just run the script:
$ tools/docs/test_doc_build.py -b
and wait (*) for it to download supported versions and test if this breaks
something. Notice that "-b" picks only the most significant versions:
DEFAULT_VERSIONS_TO_TEST = [
(3, 4, 3), # Minimal supported version
(5, 3, 0), # CentOS Stream 9 / AlmaLinux 9
(6, 1, 1), # Debian 12
(7, 2, 1), # openSUSE Leap 15.6
(7, 2, 6), # Ubuntu 24.04 LTS
(7, 4, 7), # Ubuntu 24.10
(7, 3, 0), # openSUSE Tumbleweed
(8, 1, 3), # Fedora 42
(8, 2, 3) # Latest version - covers rolling distros
]
e.g. the ones found on distros up to Fedora 42 and the latest version
on that time.
to be really sure, use "-f" to test all possible versions.
(*) even with the simplified version checks, ti runs for quite a while:
some versions take ~20 mins to build docs.
-
Jon,
I'll likely submit a patch soon to add 9.0 and 9.1 to the above list,
after finish running the tests here to see if the scripts need other
updates.
Thanks,
Mauro
next prev parent reply other threads:[~2026-10-14 21:46 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-02 23:01 Karl Mehltretter
2026-10-14 17:08 ` Jonathan Corbet
2026-10-14 21:46 ` Mauro Carvalho Chehab [this message]
2026-10-15 7:03 ` Karl Mehltretter
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=20261014233956.605e0960@foz.lan \
--to=mchehab+huawei@kernel.org \
--cc=corbet@lwn.net \
--cc=kmehltretter@gmail.com \
--cc=kuba@kernel.org \
--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
all inboxes | Powered by JetHome®