From: Akira Yokosawa <akiyks@gmail.com>
To: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>,
Jonathan Corbet <corbet@lwn.net>
Cc: linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
Randy Dunlap <rdunlap@infradead.org>,
Jani Nikula <jani.nikula@linux.intel.com>,
Akira Yokosawa <akiyks@gmail.com>
Subject: Re: [PATCH v3 0/8] Collect documentation-related tools under /tools/docs
Date: Mon, 27 Oct 2025 10:59:22 +0900 [thread overview]
Message-ID: <cb301be6-8d51-4872-8722-60d0accb7387@gmail.com> (raw)
In-Reply-To: <20251026073405.0672c9dd@sal.lan>
On Sun, 26 Oct 2025 07:34:05 -0300, Mauro Carvalho Chehab wrote:
> Em Sun, 26 Oct 2025 00:14:23 +0900
> Akira Yokosawa <akiyks@gmail.com> escreveu:
>
>> On Fri, 24 Oct 2025 14:08:21 -0600, Jonathan Corbet wrote:
>>> Our documentation-related tools are spread out over various directories;
>>> several are buried in the scripts/ dumping ground. That makes them harder
>>> to discover and harder to maintain.
>>>
>>> Recent work has started accumulating our documentation-related tools in
>>> /tools/docs. This series completes that task, moving the rest of our
>>> various utilities there, hopefully fixing up all of the relevant references
>>> in the process.
>>>
>>> At the end, rather than move the old, Perl kernel-doc, I simply removed it.
>>>
>>> The big elephant lurking in this small room is the home for Python modules;
>>> I left them under scripts/lib, but that is an even less appropriate place
>>> than it was before. I would propose either tools/python or lib/python;
>>> thoughts on that matter welcome.
>>>
>>> Changes in v3:
>>> - Now with more caffeine! Properly based on docs-next.
>>
>> :-) :-)
>>
>> WRT the build error from test robot, it looks to me like we need these
>> final touches:
>>
>> diff --git a/Documentation/conf.py b/Documentation/conf.py
>> index 8e3df5db858e..fbd8e3ae23ea 100644
>> --- a/Documentation/conf.py
>> +++ b/Documentation/conf.py
>> @@ -582,7 +582,7 @@ pdf_documents = [
>> # kernel-doc extension configuration for running Sphinx directly (e.g. by Read
>> # the Docs). In a normal build, these are supplied from the Makefile via command
>> # line arguments.
>> -kerneldoc_bin = "../tools/docs/kernel-doc.py"
>> +kerneldoc_bin = "../tools/docs/kernel-doc"
>> kerneldoc_srctree = ".."
>>
>> def setup(app):
>> diff --git a/Documentation/sphinx/kerneldoc.py b/Documentation/sphinx/kerneldoc.py
>> index 2586b4d4e494..3c815b40026b 100644
>> --- a/Documentation/sphinx/kerneldoc.py
>> +++ b/Documentation/sphinx/kerneldoc.py
>> @@ -289,13 +289,8 @@ def setup_kfiles(app):
>>
>> kerneldoc_bin = app.env.config.kerneldoc_bin
>>
>> - if kerneldoc_bin and kerneldoc_bin.endswith("kernel-doc.py"):
>> - print("Using Python kernel-doc")
>> - out_style = RestFormat()
>> - kfiles = KernelFiles(out_style=out_style, logger=logger)
>> - else:
>> - print(f"Using {kerneldoc_bin}")
>> -
>> + out_style = RestFormat()
>> + kfiles = KernelFiles(out_style=out_style, logger=logger)
>
> Patch is incomplete, as it doesn't drop the logic which forks
> kernel-doc script run, but see below.
>
>> def setup(app):
>> app.add_config_value('kerneldoc_bin', None, 'env')
>> diff --git a/Makefile b/Makefile
>> index d6ff0af5cca6..33b1db1cc0cf 100644
>> --- a/Makefile
>> +++ b/Makefile
>> @@ -460,7 +460,7 @@ HOSTPKG_CONFIG = pkg-config
>>
>> # the KERNELDOC macro needs to be exported, as scripts/Makefile.build
>> # has a logic to call it
>> -KERNELDOC = $(srctree)/tools/docs/kernel-doc.py
>> +KERNELDOC = $(srctree)/tools/docs/kernel-doc
>> export KERNELDOC
>>
>> KBUILD_USERHOSTCFLAGS := -Wall -Wmissing-prototypes -Wstrict-prototypes \
>>
>> -----------------------------------------------------------------
>>
>> The change in Documentation/sphinx/kerneldoc.py is needed because
>>
>> kerneldoc_bin == ".../kernel-doc.py"
>>
>> indicated loading it as python lib into the extension, while
>>
>> kerneldoc_bin == ".../kernel-doc"
>>
>> indicated invoking it as a script.
>>
>> Now that we don't have kernel-doc.py, loading python lib looks to me
>> as a natural choice.
>>
>> Mauro, what do you think?
>
> Good point. I'm not sure about this. Yeah, on normal cases, we
> just want to run kernel-doc classes, instead of actually
> executing its binary. Yet, for debugging purposes, it might
> still be interesting to run it as separate processes.
>
> See, right now, if KERNELDOC is not used, it will use imported
> Python classes, running them directly without creating processes.
> So, it won't actually call ".../kernel-doc". On such case, in
> practice, it will actually ignore KERNELDOC when building docs.
>
> Now, (after this series), if one runs:
>
> KERNELDOC=tools/docs/kernel-doc make htmldocs
>
> it will run kernel-doc script as a process. This might be useful
> for debugging purposes.
>
> Also, please notice that KERNELDOC is used on several files:
>
> $ git grep -l KERNELDOC
> Makefile
> drivers/gpu/drm/Makefile
> drivers/gpu/drm/i915/Makefile
> include/drm/Makefile
> scripts/Makefile.build
> tools/docs/sphinx-build-wrapper
>
> IMHO, we have some alternatives here:
>
> 1. completely drop support for KERNELDOC variable.
> On such case, we need to drop from the script:
>
> - kerneldoc_bin
> - run_cmd() function
> - remove KERNELDOC from Makefiles and sphinx-build-wrapper
>
> 2. keep it as is, which would help debugging (and eventually
> would allow testing two different implementations of kernel-doc
> without needing to bisect);
>
So, as far as the build regression reported by the build bot is
concerned, I think 2. is good enough.
Probably, Jon included the rename of:
scripts/kernel-doc | 1 -
scripts/kernel-doc.py => tools/docs/kernel-doc | 0
16 files changed, 22 insertions(+), 24 deletions(-)
delete mode 120000 scripts/kernel-doc
rename scripts/kernel-doc.py => tools/docs/kernel-doc (100%)
in 6/8 considering it the right thing to do.
Let's keep the symlink of kernel-doc --> kernel-doc.py, at least for the
time being.
Further tweaks and cleanups around KERNELDOC can wait.
Thanks, Akira
next prev parent reply other threads:[~2025-10-27 1:59 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-24 20:08 [PATCH v3 0/8] Collect documentation-related tools under /tools/docs Jonathan Corbet
2025-10-24 20:08 ` [PATCH v3 1/8] docs: Move the "features" tools to tools/docs Jonathan Corbet
2025-10-24 20:08 ` [PATCH v3 2/8] docs: move checktransupdate.py " Jonathan Corbet
2025-10-24 20:08 ` [PATCH v3 3/8] docs: move scripts/documentation-file-ref-check " Jonathan Corbet
2025-10-24 20:08 ` [PATCH v3 4/8] docs: move get_abi.py " Jonathan Corbet
2025-10-24 20:08 ` [PATCH v3 5/8] docs: move test_doc_build.py " Jonathan Corbet
2025-10-24 20:08 ` [PATCH v3 6/8] docs: move kernel-doc " Jonathan Corbet
2025-10-25 7:14 ` kernel test robot
2025-10-24 20:08 ` [PATCH v3 7/8] docs: move find-unused-docs.sh " Jonathan Corbet
2025-10-24 20:08 ` [PATCH v3 8/8] docs: remove kernel-doc.pl Jonathan Corbet
2025-10-25 2:33 ` [PATCH v3 0/8] Collect documentation-related tools under /tools/docs Mauro Carvalho Chehab
2025-10-25 15:14 ` Akira Yokosawa
2025-10-26 10:34 ` Mauro Carvalho Chehab
2025-10-26 21:53 ` Randy Dunlap
2025-11-07 10:30 ` Mauro Carvalho Chehab
2025-10-27 1:59 ` Akira Yokosawa [this message]
2025-10-27 17:04 ` Jonathan Corbet
2025-10-28 23:15 ` Jonathan Corbet
2025-11-07 10:27 ` Mauro Carvalho Chehab
2025-11-07 10:34 ` Mauro Carvalho Chehab
2025-10-26 21:44 ` Randy Dunlap
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=cb301be6-8d51-4872-8722-60d0accb7387@gmail.com \
--to=akiyks@gmail.com \
--cc=corbet@lwn.net \
--cc=jani.nikula@linux.intel.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mchehab+huawei@kernel.org \
--cc=rdunlap@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