After commit 778b8ebe5192 ("docs: Move the python libraries to
tools/lib/python"), building an external module with any value of W=
against the output of install-extmod-build fails with:

  $ make -C /usr/lib/modules/6.19.0-rc7-00108-g4d310797262f/build M=$PWD W=1
  make: Entering directory '/usr/lib/modules/6.19.0-rc7-00108-g4d310797262f/build'
  make[1]: Entering directory '...'
    CC [M] ...
  Traceback (most recent call last):
    File "/usr/lib/modules/6.19.0-rc7-00108-g4d310797262f/build/scripts/kernel-doc.py", line 339, in <module>
      main()
      ~~~~^^
    File "/usr/lib/modules/6.19.0-rc7-00108-g4d310797262f/build/scripts/kernel-doc.py", line 295, in main
      from kdoc.kdoc_files import KernelFiles             # pylint: disable=C0415
      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  ModuleNotFoundError: No module named 'kdoc'

scripts/lib was included in the build directory from find_in_scripts but
after the move to tools/lib/python, it is no longer included, breaking
kernel-doc.py.

Commit eba6ffd126cd ("docs: kdoc: move kernel-doc to tools/docs") breaks
this even further by moving kernel-doc outside of scripts as well, so it
cannot be found when called by cmd_checkdoc.

  $ make -C /usr/lib/modules/6.19.0-rc7-next-20260130/build M=$PWD W=1
  make: Entering directory '/usr/lib/modules/6.19.0-rc7-next-20260130/build'
  make[1]: Entering directory '...'
    CC [M]  ...
  python3: can't open file '/usr/lib/modules/6.19.0-rc7-next-20260130/build/tools/docs/kernel-doc': [Errno 2] No such file or directory

While kernel-doc could be useful for external modules, it is more useful
for in-tree documentation that will be build and included in htmldocs.
Rather than including it in install-extmod-build, just skip running
kernel-doc for the external module build.

Cc: stable@vger.kernel.org
Fixes: 778b8ebe5192 ("docs: Move the python libraries to tools/lib/python")
Reported-by: Rong Zhang <i@rong.moe>
Closes: https://lore.kernel.org/20260129175321.415295-1-i@rong.moe/
Reviewed-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
---
This is an alternative to Rong's proposed fix for the first error:

  https://lore.kernel.org/20260129175321.415295-1-i@rong.moe/

I noticed the second one by inspection of -next and further testing.
---
 scripts/Makefile.build | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/scripts/Makefile.build b/scripts/Makefile.build
index 5037f4715d74..f01d7957edf7 100644
--- a/scripts/Makefile.build
+++ b/scripts/Makefile.build
@@ -166,11 +166,13 @@ else ifeq ($(KBUILD_CHECKSRC),2)
         cmd_force_checksrc = $(CHECK) $(CHECKFLAGS) $(c_flags) $<
 endif
 
+ifeq ($(KBUILD_EXTMOD),)
 ifneq ($(KBUILD_EXTRA_WARN),)
   cmd_checkdoc = PYTHONDONTWRITEBYTECODE=1 $(PYTHON3) $(KERNELDOC) -none $(KDOCFLAGS) \
         $(if $(findstring 2, $(KBUILD_EXTRA_WARN)), -Wall) \
         $<
 endif
+endif
 
 # Compile C sources (.c)
 # ---------------------------------------------------------------------------

---
base-commit: 63804fed149a6750ffd28610c5c1c98cce6bd377
change-id: 20260130-kbuild-skip-kernel-doc-extmod-276584e7b2b0

Best regards,
--  
Nathan Chancellor <nathan@kernel.org>

On Fri, 30 Jan 2026 14:37:47 -0700, Nathan Chancellor wrote:
> After commit 778b8ebe5192 ("docs: Move the python libraries to
> tools/lib/python"), building an external module with any value of W=
> against the output of install-extmod-build fails with:
> 
>   $ make -C /usr/lib/modules/6.19.0-rc7-00108-g4d310797262f/build M=$PWD W=1
>   make: Entering directory '/usr/lib/modules/6.19.0-rc7-00108-g4d310797262f/build'
>   make[1]: Entering directory '...'
>     CC [M] ...
>   Traceback (most recent call last):
>     File "/usr/lib/modules/6.19.0-rc7-00108-g4d310797262f/build/scripts/kernel-doc.py", line 339, in <module>
>       main()
>       ~~~~^^
>     File "/usr/lib/modules/6.19.0-rc7-00108-g4d310797262f/build/scripts/kernel-doc.py", line 295, in main
>       from kdoc.kdoc_files import KernelFiles             # pylint: disable=C0415
>       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>   ModuleNotFoundError: No module named 'kdoc'
> 
> [...]

Applied to kbuild/linux.git (kbuild-fixes-unstable), thanks!

[1/1] kbuild: Do not run kernel-doc when building external modules
      https://git.kernel.org/kbuild/c/8e249948

Please look out for regression or issue reports or other follow up
comments, as they may result in the patch/series getting dropped,
reverted or modified (e.g. trailers). Patches applied to the
kbuild-fixes-unstable branch are accepted pending wider testing in
linux-next and any post-commit review; they will generally be moved
to the kbuild-fixes branch in a week if no issues are found.

Best regards,
-- 
Nicolas

On Sun, Feb 1, 2026 at 12:15 AM Nicolas Schier <nsc@kernel.org> wrote:
>
> On Fri, 30 Jan 2026 14:37:47 -0700, Nathan Chancellor wrote:
> > After commit 778b8ebe5192 ("docs: Move the python libraries to
> > tools/lib/python"), building an external module with any value of W=
> > against the output of install-extmod-build fails with:
> >
> >   $ make -C /usr/lib/modules/6.19.0-rc7-00108-g4d310797262f/build M=$PWD W=1
> >   make: Entering directory '/usr/lib/modules/6.19.0-rc7-00108-g4d310797262f/build'
> >   make[1]: Entering directory '...'
> >     CC [M] ...
> >   Traceback (most recent call last):
> >     File "/usr/lib/modules/6.19.0-rc7-00108-g4d310797262f/build/scripts/kernel-doc.py", line 339, in <module>
> >       main()
> >       ~~~~^^
> >     File "/usr/lib/modules/6.19.0-rc7-00108-g4d310797262f/build/scripts/kernel-doc.py", line 295, in main
> >       from kdoc.kdoc_files import KernelFiles             # pylint: disable=C0415
> >       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> >   ModuleNotFoundError: No module named 'kdoc'
> >
> > [...]
>
> Applied to kbuild/linux.git (kbuild-fixes-unstable), thanks!


I believe this is a wrong direction to go.

Since kernel-doc is a part of Kbuild,
all dependent libraries should exist under scripts/.


--
Best Regards
Masahiro Yamada

On Wed, 04 Feb 2026, Masahiro Yamada <masahiroy@kernel.org> wrote:
> Since kernel-doc is a part of Kbuild,
> all dependent libraries should exist under scripts/.

Huh. I've always wondered why all the Kbuild makefiles are placed in
scripts/, which appears to be a haphazard collection of, well, scripts
and tools. But then you also have tools/.

I've followed the kernel-doc refactoring from the sidelines, commenting
on some things, but it never crossed my mind the build shouldn't depend
on something outside of scripts/. (That's what I'm inferring here
anyway.) And apparently that thought didn't occur to a lot of other
people either, with even more kernel experience than myself.

Sounds like the kernel config and build system would deserve a top-level
directory like build/ or kbuild/, which collects everything needed for
the build, nothing more, nothing less. Because scripts/ is not *that*.

I understand all of this may be a historical accident, and possibly too
painful to fix now, but is any of this documented anywhere either?


BR,
Jani.


-- 
Jani Nikula, Intel

On Wed, Feb 04, 2026 at 11:10:37AM +0200, Jani Nikula wrote:
> On Wed, 04 Feb 2026, Masahiro Yamada <masahiroy@kernel.org> wrote:
> > Since kernel-doc is a part of Kbuild,
> > all dependent libraries should exist under scripts/.
> 
> Huh. I've always wondered why all the Kbuild makefiles are placed in
> scripts/, which appears to be a haphazard collection of, well, scripts
> and tools. But then you also have tools/.

From the kbuild perspective, as Masahiro mentioned, every tooling
related to kernel builds, kbuild or kconfig should be placed in
scripts/.  The tools/ subtree isn't using kbuild; rules, definitionas
and other expectations that are valid for kbuild may not be true in
tools/, cp. commit 6e6ef2da3a28f [1].

Unfortunately, there _are_ things in tools/ that are required for kernel
builds (e.g. objtool), but there is no consent on moving these parts out
of the tools/ subtree [2].

> I've followed the kernel-doc refactoring from the sidelines, commenting
> on some things, but it never crossed my mind the build shouldn't depend
> on something outside of scripts/. (That's what I'm inferring here
> anyway.) And apparently that thought didn't occur to a lot of other
> people either, with even more kernel experience than myself.

Yes, I also saw the changes fly by but did not think about the
implications.

> Sounds like the kernel config and build system would deserve a top-level
> directory like build/ or kbuild/, which collects everything needed for
> the build, nothing more, nothing less. Because scripts/ is not *that*.

Well, sounds straight forward at first, but where should we make the cut
between kbuild and non-kbuild?  I admit that there are some scripts
below scripts/ that I'd rather label as "contrib", but I don't think
that these are too much.

> I understand all of this may be a historical accident, and possibly too
> painful to fix now, but is any of this documented anywhere either?

No, I am afraid it isn't.

Kind regards,
Nicolas


[1]: https://git.kernel.org/kbuild/c/6e6ef2da3a28f
[2]: https://lore.kernel.org/linux-kbuild/1551764896-8453-3-git-send-email-yamada.masahiro@socionext.com/

On Wed, 04 Feb 2026, Nicolas Schier <nsc@kernel.org> wrote:
> Well, sounds straight forward at first, but where should we make the
> cut between kbuild and non-kbuild?

I'll reply hypothetically, just for the sake of discussion, because
realistically, I don't think any of this is going to happen.

IMO the cut should be, "Is this required for configuring and building
the kernel"?

scripts/ just sounds like a dumping ground for random scripts, and
kbuild should be somewhere else. And let scripts/ be the dumping ground
that it is. If kbuild was under kbuild/, nobody in their right mind
would suggest adding random unrelated scripts there.

If kbuild depends on some things like objtool from somewhere else, so be
it, but at least don't pollute kbuild with unrelated things.

> I admit that there are some scripts below scripts/ that I'd rather
> label as "contrib", but I don't think that these are too much.

I've got to disagree there. I think there's so much that it's hard to
follow what is and isn't actually required for build.

At a *very* quick glance, there are things like checkpatch.pl,
get_maintainer.pl, anything coccinelle, bash-completion, Lindent,
macro_checker.py, bloat-o-meter, bootgraph.pl, etc, etc.

BR,
Jani.

-- 
Jani Nikula, Intel

On Wed, 04 Feb 2026 12:39:22 +0200
Jani Nikula <jani.nikula@linux.intel.com> wrote:

> On Wed, 04 Feb 2026, Nicolas Schier <nsc@kernel.org> wrote:
> > Well, sounds straight forward at first, but where should we make the
> > cut between kbuild and non-kbuild?  
> 
> I'll reply hypothetically, just for the sake of discussion, because
> realistically, I don't think any of this is going to happen.
> 
> IMO the cut should be, "Is this required for configuring and building
> the kernel"?

Agreed. Going further, maybe the best would be to define it per make
target, placing them on 3 groups:

- kbuild - make targets related to actually build the kernel;
- docs-build - make targets related to build docs;
- non-kbuild - the remaining random stuff over there.

To properly define what should be there, maybe the best would be to
look at "make help" and define what belongs to each group:


Cleaning targets:
- mostly kbuild (documentation is also part of cleaning targets)

Configuration targets:
- kbuild

Configuration topic targets:
- kbuild (I guess)

Other generic targets:
- kbuild: all, vmlinux, modules, modules_install, vdso_install, dir/*
- There is a grey area here with targets like cscope, gtags, tags/TAGS.
  I would consider those as non-kbuild.

Static analysers, Tools, Kernel selftest:
- I would also consider those as no-kbuild

Rust targets:
- dir/*: kbuild
- the other ones seem ancillary tooling. Probably, non-kbuild

Userspace tools targets:
- for sure no-kbuild

Kernel packaging:
- no-kbuild

Documentation targets:
- docs-build

Architecture-specific targets:
- kbuild

> 
> scripts/ just sounds like a dumping ground for random scripts, and
> kbuild should be somewhere else. And let scripts/ be the dumping ground
> that it is. If kbuild was under kbuild/, nobody in their right mind
> would suggest adding random unrelated scripts there.
> 
> If kbuild depends on some things like objtool from somewhere else, so be
> it, but at least don't pollute kbuild with unrelated things.

Agreed. Yet, better to document it somewhere.

> 
> > I admit that there are some scripts below scripts/ that I'd rather
> > label as "contrib", but I don't think that these are too much.  
> 
> I've got to disagree there. I think there's so much that it's hard to
> follow what is and isn't actually required for build.
> 
> At a *very* quick glance, there are things like checkpatch.pl,
> get_maintainer.pl, anything coccinelle, bash-completion, Lindent,
> macro_checker.py, bloat-o-meter, bootgraph.pl, etc, etc.

So true. on its current state, scripts/ is a place where people
ended adding random stuff over time.

-- 
Thanks,
Mauro

On Wed, Feb 04, 2026 at 11:11:33AM +0100, Nicolas Schier wrote:
> On Wed, Feb 04, 2026 at 11:10:37AM +0200, Jani Nikula wrote:
> > On Wed, 04 Feb 2026, Masahiro Yamada <masahiroy@kernel.org> wrote:
> > > Since kernel-doc is a part of Kbuild,
> > > all dependent libraries should exist under scripts/.
> > 
> > Huh. I've always wondered why all the Kbuild makefiles are placed in
> > scripts/, which appears to be a haphazard collection of, well, scripts
> > and tools. But then you also have tools/.
> 
> From the kbuild perspective, as Masahiro mentioned, every tooling
> related to kernel builds, kbuild or kconfig should be placed in
> scripts/.  The tools/ subtree isn't using kbuild; rules, definitionas
> and other expectations that are valid for kbuild may not be true in
> tools/, cp. commit 6e6ef2da3a28f [1].
> 
> Unfortunately, there _are_ things in tools/ that are required for kernel
> builds (e.g. objtool), but there is no consent on moving these parts out
> of the tools/ subtree [2].
> 
> > I've followed the kernel-doc refactoring from the sidelines, commenting
> > on some things, but it never crossed my mind the build shouldn't depend
> > on something outside of scripts/. (That's what I'm inferring here
> > anyway.) And apparently that thought didn't occur to a lot of other
> > people either, with even more kernel experience than myself.
> 
> Yes, I also saw the changes fly by but did not think about the
> implications.
> 
> > Sounds like the kernel config and build system would deserve a top-level
> > directory like build/ or kbuild/, which collects everything needed for
> > the build, nothing more, nothing less. Because scripts/ is not *that*.
> 
> Well, sounds straight forward at first, but where should we make the cut
> between kbuild and non-kbuild?  I admit that there are some scripts
> below scripts/ that I'd rather label as "contrib", but I don't think
> that these are too much.

There are all sorts of stuff there. Just documentation has 15 scripts
that was either sitting there or were written directly at tools/docs,
as part of the discussion process of moving things out of it. Several
of them belongs to in-kernel-tree build chain.

Just my two cents, but I guess a kbuild/ and/or tools/kbuild directory
makes sense on my eyes. Yet, I wouldn't mix it with the documentation
build itself.

> 
> > I understand all of this may be a historical accident, and possibly too
> > painful to fix now, but is any of this documented anywhere either?
> 
> No, I am afraid it isn't.
> 
> Kind regards,
> Nicolas
> 
> 
> [1]: https://git.kernel.org/kbuild/c/6e6ef2da3a28f
> [2]: https://lore.kernel.org/linux-kbuild/1551764896-8453-3-git-send-email-yamada.masahiro@socionext.com/

-- 
Thanks,
Mauro

Hi Masahiro,

Good to see you around.

On Wed, Feb 04, 2026 at 04:02:10PM +0900, Masahiro Yamada wrote:
> On Sun, Feb 1, 2026 at 12:15 AM Nicolas Schier <nsc@kernel.org> wrote:
> >
> > On Fri, 30 Jan 2026 14:37:47 -0700, Nathan Chancellor wrote:
> > > After commit 778b8ebe5192 ("docs: Move the python libraries to
> > > tools/lib/python"), building an external module with any value of W=
> > > against the output of install-extmod-build fails with:
> > >
> > >   $ make -C /usr/lib/modules/6.19.0-rc7-00108-g4d310797262f/build M=$PWD W=1
> > >   make: Entering directory '/usr/lib/modules/6.19.0-rc7-00108-g4d310797262f/build'
> > >   make[1]: Entering directory '...'
> > >     CC [M] ...
> > >   Traceback (most recent call last):
> > >     File "/usr/lib/modules/6.19.0-rc7-00108-g4d310797262f/build/scripts/kernel-doc.py", line 339, in <module>
> > >       main()
> > >       ~~~~^^
> > >     File "/usr/lib/modules/6.19.0-rc7-00108-g4d310797262f/build/scripts/kernel-doc.py", line 295, in main
> > >       from kdoc.kdoc_files import KernelFiles             # pylint: disable=C0415
> > >       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > >   ModuleNotFoundError: No module named 'kdoc'
> > >
> > > [...]
> >
> > Applied to kbuild/linux.git (kbuild-fixes-unstable), thanks!
> 
> 
> I believe this is a wrong direction to go.
> 
> Since kernel-doc is a part of Kbuild,
> all dependent libraries should exist under scripts/.

Is this around the recent moves such as 778b8ebe5192? I guess Kbuild was
never consulted on that change and I missed eba6ffd126cd, despite being
CC'd, so that is on me.

I did wonder if it was worth it to package these files in a previous
change but Mauro seemed somewhat opposed to it (but maybe I
misinterpreted something):

  https://lore.kernel.org/20260130063056.72fbe458@foz.lan/

Perhaps tools/docs could be moved to scripts/docs and tools/lib/python
could be moved to just lib/python to have everything live logically
outside of tools/ and make it easier to package?

Cheers,
Nathan

On Wed, Feb 04, 2026 at 12:39:03AM -0700, Nathan Chancellor wrote:
> Hi Masahiro,
> 
> Good to see you around.
> 
> On Wed, Feb 04, 2026 at 04:02:10PM +0900, Masahiro Yamada wrote:
> > On Sun, Feb 1, 2026 at 12:15 AM Nicolas Schier <nsc@kernel.org> wrote:
> > >
> > > On Fri, 30 Jan 2026 14:37:47 -0700, Nathan Chancellor wrote:
> > > > After commit 778b8ebe5192 ("docs: Move the python libraries to
> > > > tools/lib/python"), building an external module with any value of W=
> > > > against the output of install-extmod-build fails with:
> > > >
> > > >   $ make -C /usr/lib/modules/6.19.0-rc7-00108-g4d310797262f/build M=$PWD W=1
> > > >   make: Entering directory '/usr/lib/modules/6.19.0-rc7-00108-g4d310797262f/build'
> > > >   make[1]: Entering directory '...'
> > > >     CC [M] ...
> > > >   Traceback (most recent call last):
> > > >     File "/usr/lib/modules/6.19.0-rc7-00108-g4d310797262f/build/scripts/kernel-doc.py", line 339, in <module>
> > > >       main()
> > > >       ~~~~^^
> > > >     File "/usr/lib/modules/6.19.0-rc7-00108-g4d310797262f/build/scripts/kernel-doc.py", line 295, in main
> > > >       from kdoc.kdoc_files import KernelFiles             # pylint: disable=C0415
> > > >       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > > >   ModuleNotFoundError: No module named 'kdoc'
> > > >
> > > > [...]
> > >
> > > Applied to kbuild/linux.git (kbuild-fixes-unstable), thanks!
> > 
> > 
> > I believe this is a wrong direction to go.
> > 
> > Since kernel-doc is a part of Kbuild,
> > all dependent libraries should exist under scripts/.
> 
> Is this around the recent moves such as 778b8ebe5192? I guess Kbuild was
> never consulted on that change and I missed eba6ffd126cd, despite being
> CC'd, so that is on me.
> 
> I did wonder if it was worth it to package these files in a previous
> change but Mauro seemed somewhat opposed to it (but maybe I
> misinterpreted something):
> 
>   https://lore.kernel.org/20260130063056.72fbe458@foz.lan/

Not really opposed. The point is that, on a normal run, kernel-doc
is executed with -none, to check if are there a trouble with the
kernel-doc markup (there's a kconfig option for such purpose).
Also, it is not the only tool that it is executed on such case,
on a normal build. See docs/Makefile (*):

    ifneq ($(MAKECMDGOALS),cleandocs)
    # Check for broken documentation file references
    ifeq ($(CONFIG_WARN_MISSING_DOCUMENTS),y)
    $(shell $(srctree)/tools/docs/documentation-file-ref-check --warn)
    endif

    # Check for broken ABI files
    ifeq ($(CONFIG_WARN_ABI_ERRORS),y)
    $(shell $(srctree)/tools/docs/get_abi.py --dir $(srctree)/Documentation/ABI validate)
    endif
    endif

(*) The only difference is that kernel-doc call is currently sitting
    at scripts/Makefile.build. Perhaps it could make sense to move
    it to docs/Makefile.

-

I think it is not worth running any such documentation-validation-tools
when doing OOT driver builds, as their goal is to ensure a good
quality of documentation within the Kernel, and OOT drivers usually
have a lot more problems than just documentation, but it is up to you.
I'm ok with either solution.
 
> Perhaps tools/docs could be moved to scripts/docs and tools/lib/python
> could be moved to just lib/python to have everything live logically
> outside of tools/ and make it easier to package?

The idea of moving it out of scripts is because scripts became
a no-man's land, with lots of mixed stuff. From my side, I don't
care much about its location, provided that the path is very short.

-

That's said, if you want htmldocs/mandocs/... targets to work
with OOT builds, you don't really need kernel-doc executable, 
as Sphinx uses kdoc libraries directly. Yet, you need a lot
more:

1) tools executed by docs/Makefile:

    tools/docs/sphinx-build-wrapper
    tools/docs/sphinx-pre-install

2) Sphinx config and extensions:

    Documentation/conf.py
    Documentation/sphinx/
    Documentation/sphinx-includes/
    Documentation/sphinx-static/

3) Libraries used by sphinx-build-wrapper and sphinx extensions:

    tools/lib/python/jobserver.py
    tools/lib/python/abi/
    tools/lib/python/feat/
    tools/lib/python/kdoc/

You can also install optional command line tools, which
are helpful to run the code inside abi/feat/kdoc outside
Sphinx build:

    tools/docs/kernel-doc
    tools/docs/get_abi.py
    tools/docs/get_feat.py
    tools/docs/parse-headers.py
  
Regards,
Mauro

On 1/30/26 1:37 PM, Nathan Chancellor wrote:
> After commit 778b8ebe5192 ("docs: Move the python libraries to
> tools/lib/python"), building an external module with any value of W=
> against the output of install-extmod-build fails with:
> 
>   $ make -C /usr/lib/modules/6.19.0-rc7-00108-g4d310797262f/build M=$PWD W=1
>   make: Entering directory '/usr/lib/modules/6.19.0-rc7-00108-g4d310797262f/build'
>   make[1]: Entering directory '...'
>     CC [M] ...
>   Traceback (most recent call last):
>     File "/usr/lib/modules/6.19.0-rc7-00108-g4d310797262f/build/scripts/kernel-doc.py", line 339, in <module>
>       main()
>       ~~~~^^
>     File "/usr/lib/modules/6.19.0-rc7-00108-g4d310797262f/build/scripts/kernel-doc.py", line 295, in main
>       from kdoc.kdoc_files import KernelFiles             # pylint: disable=C0415
>       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>   ModuleNotFoundError: No module named 'kdoc'
> 
> scripts/lib was included in the build directory from find_in_scripts but
> after the move to tools/lib/python, it is no longer included, breaking
> kernel-doc.py.
> 
> Commit eba6ffd126cd ("docs: kdoc: move kernel-doc to tools/docs") breaks
> this even further by moving kernel-doc outside of scripts as well, so it
> cannot be found when called by cmd_checkdoc.
> 
>   $ make -C /usr/lib/modules/6.19.0-rc7-next-20260130/build M=$PWD W=1
>   make: Entering directory '/usr/lib/modules/6.19.0-rc7-next-20260130/build'
>   make[1]: Entering directory '...'
>     CC [M]  ...
>   python3: can't open file '/usr/lib/modules/6.19.0-rc7-next-20260130/build/tools/docs/kernel-doc': [Errno 2] No such file or directory
> 
> While kernel-doc could be useful for external modules, it is more useful
> for in-tree documentation that will be build and included in htmldocs.
> Rather than including it in install-extmod-build, just skip running
> kernel-doc for the external module build.
> 
> Cc: stable@vger.kernel.org
> Fixes: 778b8ebe5192 ("docs: Move the python libraries to tools/lib/python")
> Reported-by: Rong Zhang <i@rong.moe>
> Closes: https://lore.kernel.org/20260129175321.415295-1-i@rong.moe/
> Reviewed-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
> Signed-off-by: Nathan Chancellor <nathan@kernel.org>


LGTM.
Reviewed-by: Randy Dunlap <rdunlap@infradead.org>

Thanks.

> ---
> This is an alternative to Rong's proposed fix for the first error:
> 
>   https://lore.kernel.org/20260129175321.415295-1-i@rong.moe/
> 
> I noticed the second one by inspection of -next and further testing.
> ---
>  scripts/Makefile.build | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/scripts/Makefile.build b/scripts/Makefile.build
> index 5037f4715d74..f01d7957edf7 100644
> --- a/scripts/Makefile.build
> +++ b/scripts/Makefile.build
> @@ -166,11 +166,13 @@ else ifeq ($(KBUILD_CHECKSRC),2)
>          cmd_force_checksrc = $(CHECK) $(CHECKFLAGS) $(c_flags) $<
>  endif
>  
> +ifeq ($(KBUILD_EXTMOD),)
>  ifneq ($(KBUILD_EXTRA_WARN),)
>    cmd_checkdoc = PYTHONDONTWRITEBYTECODE=1 $(PYTHON3) $(KERNELDOC) -none $(KDOCFLAGS) \
>          $(if $(findstring 2, $(KBUILD_EXTRA_WARN)), -Wall) \
>          $<
>  endif
> +endif
>  
>  # Compile C sources (.c)
>  # ---------------------------------------------------------------------------
> 
> ---
> base-commit: 63804fed149a6750ffd28610c5c1c98cce6bd377
> change-id: 20260130-kbuild-skip-kernel-doc-extmod-276584e7b2b0
> 
> Best regards,
> --  
> Nathan Chancellor <nathan@kernel.org>
> 
> 

-- 
~Randy