scripts/package/install-extmod-build | 1 + 1 file changed, 1 insertion(+)
scripts/lib has been moved to tools/lib/python recently. Since then, I
got a regression while building out-of-tree modules with W=<anything>
(1/2/3/c/e):
$ make -C /lib/modules/6.19.0-rc6/build/ M="$(pwd)" modules V=1 W=1
[...]
make -f /usr/src/linux-headers-6.19.0-rc6/scripts/Makefile.build obj=. need-builtin=1 need-modorder=1
# CC [M] mod.o
[...]
# cmd_checkdoc mod.o
PYTHONDONTWRITEBYTECODE=1 python3 /usr/src/linux-headers-6.19.0-rc6/scripts/kernel-doc.py -none mod.c
Traceback (most recent call last):
File "/usr/src/linux-headers-6.19.0-rc6/scripts/kernel-doc.py", line 339, in <module>
main()
~~~~^^
File "/usr/src/linux-headers-6.19.0-rc6/scripts/kernel-doc.py", line 295, in main
from kdoc.kdoc_files import KernelFiles # pylint: disable=C0415
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
ModuleNotFoundError: No module named 'kdoc'
make[3]: *** [/usr/src/linux-headers-6.19.0-rc6/scripts/Makefile.build:287: mod.o] Error 1
Fix it by installing python libraries from tools/lib/python.
Fixes: 778b8ebe5192 ("docs: Move the python libraries to tools/lib/python")
Signed-off-by: Rong Zhang <i@rong.moe>
---
scripts/package/install-extmod-build | 1 +
1 file changed, 1 insertion(+)
diff --git a/scripts/package/install-extmod-build b/scripts/package/install-extmod-build
index 2576cf7902dbb..a15de610afed3 100755
--- a/scripts/package/install-extmod-build
+++ b/scripts/package/install-extmod-build
@@ -20,6 +20,7 @@ mkdir -p "${destdir}"
(
cd "${srctree}"
echo Makefile
+ echo tools/lib/python # required by scripts
find "arch/${SRCARCH}" -maxdepth 1 -name 'Makefile*'
find "arch/${SRCARCH}" -name generated -prune -o -name include -type d -print
find "arch/${SRCARCH}" -name Kbuild.platforms -o -name Platform
base-commit: 8dfce8991b95d8625d0a1d2896e42f93b9d7f68d
--
2.51.0+ Jon, Mauro, and linux-doc
FWIW, this ended up in my spam folder but I saw it on linux-kbuild.
On Fri, Jan 30, 2026 at 01:49:55AM +0800, Rong Zhang wrote:
> scripts/lib has been moved to tools/lib/python recently. Since then, I
> got a regression while building out-of-tree modules with W=<anything>
> (1/2/3/c/e):
Hmmm, the W=<anything> bit seems wrong (or at the very least, c/e)... we
should probably change that to just being enabled at W=1 (but that is
tangential to this patch).
> $ make -C /lib/modules/6.19.0-rc6/build/ M="$(pwd)" modules V=1 W=1
> [...]
> make -f /usr/src/linux-headers-6.19.0-rc6/scripts/Makefile.build obj=. need-builtin=1 need-modorder=1
> # CC [M] mod.o
> [...]
> # cmd_checkdoc mod.o
> PYTHONDONTWRITEBYTECODE=1 python3 /usr/src/linux-headers-6.19.0-rc6/scripts/kernel-doc.py -none mod.c
> Traceback (most recent call last):
> File "/usr/src/linux-headers-6.19.0-rc6/scripts/kernel-doc.py", line 339, in <module>
> main()
> ~~~~^^
> File "/usr/src/linux-headers-6.19.0-rc6/scripts/kernel-doc.py", line 295, in main
> from kdoc.kdoc_files import KernelFiles # pylint: disable=C0415
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> ModuleNotFoundError: No module named 'kdoc'
> make[3]: *** [/usr/src/linux-headers-6.19.0-rc6/scripts/Makefile.build:287: mod.o] Error 1
>
> Fix it by installing python libraries from tools/lib/python.
>
> Fixes: 778b8ebe5192 ("docs: Move the python libraries to tools/lib/python")
> Signed-off-by: Rong Zhang <i@rong.moe>
Thanks, this seems to be correct to me.
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
Nicolas, do you want to take this via kbuild-fixes? This should probably
have a 'Cc: stable@vger.kernel.org' on it?
Hmmm, now that I am looking at -next, Jon's move of scripts/kernel-doc
to tools/docs/ in commit eba6ffd126cd ("docs: kdoc: move kernel-doc to
tools/docs") in that tree without adding tools/docs to this list breaks
this exact same scenario, right?
> ---
> scripts/package/install-extmod-build | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/scripts/package/install-extmod-build b/scripts/package/install-extmod-build
> index 2576cf7902dbb..a15de610afed3 100755
> --- a/scripts/package/install-extmod-build
> +++ b/scripts/package/install-extmod-build
> @@ -20,6 +20,7 @@ mkdir -p "${destdir}"
> (
> cd "${srctree}"
> echo Makefile
> + echo tools/lib/python # required by scripts
> find "arch/${SRCARCH}" -maxdepth 1 -name 'Makefile*'
> find "arch/${SRCARCH}" -name generated -prune -o -name include -type d -print
> find "arch/${SRCARCH}" -name Kbuild.platforms -o -name Platform
>
> base-commit: 8dfce8991b95d8625d0a1d2896e42f93b9d7f68d
> --
> 2.51.0
>
Hi Nathan,
On Thu, 29 Jan 2026 18:11:06 -0700
Nathan Chancellor <nathan@kernel.org> wrote:
> + Jon, Mauro, and linux-doc
>
> FWIW, this ended up in my spam folder but I saw it on linux-kbuild.
>
> On Fri, Jan 30, 2026 at 01:49:55AM +0800, Rong Zhang wrote:
> > scripts/lib has been moved to tools/lib/python recently. Since then, I
> > got a regression while building out-of-tree modules with W=<anything>
> > (1/2/3/c/e):
>
> Hmmm, the W=<anything> bit seems wrong (or at the very least, c/e)... we
> should probably change that to just being enabled at W=1 (but that is
> tangential to this patch).
>
> > $ make -C /lib/modules/6.19.0-rc6/build/ M="$(pwd)" modules V=1 W=1
> > [...]
> > make -f /usr/src/linux-headers-6.19.0-rc6/scripts/Makefile.build obj=. need-builtin=1 need-modorder=1
> > # CC [M] mod.o
> > [...]
> > # cmd_checkdoc mod.o
> > PYTHONDONTWRITEBYTECODE=1 python3 /usr/src/linux-headers-6.19.0-rc6/scripts/kernel-doc.py -none mod.c
This sounds really weird, as it is trying to run scripts/kernel-doc.py
instead of tools/docs/kernel-doc. Does the out-of-tree Makefile
override KERNELDOC variable? The current version contains:
KERNELDOC = $(srctree)/tools/docs/kernel-doc
But somehow it is using the old version before the renames:
KERNELDOC = $(srctree)/scripts/kernel-doc.py
As you can see, kernel-doc.py was renamed to just kernel-doc at the
patches that moved it. Inside kernel-doc, there is this code:
LIB_DIR = "lib/kdoc"
SRC_DIR = os.path.dirname(os.path.realpath(__file__))
sys.path.insert(0, os.path.join(SRC_DIR, LIB_DIR))
which auto-detect its location and ensures that the library location
will be relative to it.
With that, if you call it outside the kernel tree, like here (on this
example, kernel root tree is at linux-next):
$ linux-next/tools/docs/kernel-doc linux-next/drivers/acpi/ -none
Warning: linux-next/drivers/acpi/fan.h:83 function parameter 'speed' not described in 'acpi_fan_speed_valid'
Warning: linux-next/drivers/acpi/fan.h:83 function parameter 'speed' not described in 'acpi_fan_speed_valid'
it works just fine.
the realpath() function even warrants that a symlink will equally
work(*):
$ linux-next/scripts/kernel-doc linux-next/drivers/acpi/ -none
Warning: linux-next/drivers/acpi/fan.h:83 function parameter 'speed' not described in 'acpi_fan_speed_valid'
Warning: linux-next/drivers/acpi/fan.h:83 function parameter 'speed' not described in 'acpi_fan_speed_valid'
(*) one of the patches of the rename patch series added a soft link:
$ ls -lctra linux-next/scripts/kernel-doc
lrwxrwxrwx 1 user user 24 Jan 23 08:53 linux-next/scripts/kernel-doc -> ../tools/docs/kernel-doc
Btw, I did a very quick test here, using an old OOT project I have
at github:
https://github.com/mchehab/xr_serial
Changing its Makefile to:
obj-m := xr_serial.o
SRCTREE=../linux-next
KERNELDIR ?= $(SRCTREE)/tools/build
KERNELDOC = $(SRCTREE)/tools/docs/kernel-doc
PWD := $(shell pwd)
EXTRA_CFLAGS := -DDEBUG=0
all:
$(MAKE) -C $(KERNELDIR) M=$(PWD)
docs:
$(KERNELDOC) .
modules_install:
$(MAKE) -C $(KERNELDIR) M=$(PWD) modules_install
install: modules_install
clean:
rm -rf *.o *~ core .depend .*.cmd *.ko *.mod.c .tmp_versions vtty built-in.a cdc-acm.mod modules.order Module.symvers xr_serial.mod
There, building docs didn't crash:
$ make docs
../linux-next/tools/docs/kernel-doc .
(none was produced, as xr_serial doesn't contain any kernel-doc
stuff, but still the tool worked properly).
It sounds to me that Rong may be using a Makefile on his OOT project
that was not updated to pick the right kernel-doc tool.
> > Traceback (most recent call last):
> > File "/usr/src/linux-headers-6.19.0-rc6/scripts/kernel-doc.py", line 339, in <module>
> > main()
> > ~~~~^^
> > File "/usr/src/linux-headers-6.19.0-rc6/scripts/kernel-doc.py", line 295, in main
> > from kdoc.kdoc_files import KernelFiles # pylint: disable=C0415
> > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > ModuleNotFoundError: No module named 'kdoc'
> > make[3]: *** [/usr/src/linux-headers-6.19.0-rc6/scripts/Makefile.build:287: mod.o] Error 1
> >
> > Fix it by installing python libraries from tools/lib/python.
> >
> > Fixes: 778b8ebe5192 ("docs: Move the python libraries to tools/lib/python")
> > Signed-off-by: Rong Zhang <i@rong.moe>
>
> Thanks, this seems to be correct to me.
>
> Reviewed-by: Nathan Chancellor <nathan@kernel.org>
>
> Nicolas, do you want to take this via kbuild-fixes? This should probably
> have a 'Cc: stable@vger.kernel.org' on it?
>
> Hmmm, now that I am looking at -next, Jon's move of scripts/kernel-doc
> to tools/docs/ in commit eba6ffd126cd ("docs: kdoc: move kernel-doc to
> tools/docs") in that tree without adding tools/docs to this list breaks
> this exact same scenario, right?
>
> > ---
> > scripts/package/install-extmod-build | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/scripts/package/install-extmod-build b/scripts/package/install-extmod-build
> > index 2576cf7902dbb..a15de610afed3 100755
> > --- a/scripts/package/install-extmod-build
> > +++ b/scripts/package/install-extmod-build
> > @@ -20,6 +20,7 @@ mkdir -p "${destdir}"
> > (
> > cd "${srctree}"
> > echo Makefile
> > + echo tools/lib/python # required by scripts
I don't know exactly how the out-of-tree logic works, but at least
in my eyes, this doesn't sound the right fix.
Regards,
Mauro
Thanks,
Mauro
On Fri, Jan 30, 2026 at 06:30:56AM +0100, Mauro Carvalho Chehab wrote:
> On Thu, 29 Jan 2026 18:11:06 -0700
> Nathan Chancellor <nathan@kernel.org> wrote:
> > On Fri, Jan 30, 2026 at 01:49:55AM +0800, Rong Zhang wrote:
...
> > > $ make -C /lib/modules/6.19.0-rc6/build/ M="$(pwd)" modules V=1 W=1
> > > [...]
> > > make -f /usr/src/linux-headers-6.19.0-rc6/scripts/Makefile.build obj=. need-builtin=1 need-modorder=1
> > > # CC [M] mod.o
> > > [...]
> > > # cmd_checkdoc mod.o
> > > PYTHONDONTWRITEBYTECODE=1 python3 /usr/src/linux-headers-6.19.0-rc6/scripts/kernel-doc.py -none mod.c
>
> This sounds really weird, as it is trying to run scripts/kernel-doc.py
> instead of tools/docs/kernel-doc. Does the out-of-tree Makefile
> override KERNELDOC variable? The current version contains:
>
> KERNELDOC = $(srctree)/tools/docs/kernel-doc
>
> But somehow it is using the old version before the renames:
>
> KERNELDOC = $(srctree)/scripts/kernel-doc.py
Well I think based on the "6.19.0-rc6" in the path above, this is
mainline, not -next, so the rename has has not happend there yet.
> Btw, I did a very quick test here, using an old OOT project I have
> at github:
>
> https://github.com/mchehab/xr_serial
...
> It sounds to me that Rong may be using a Makefile on his OOT project
> that was not updated to pick the right kernel-doc tool.
If I use that project with Rong's original command, the
linux-upstream-headers package from the pacman-pkg target (which uses
install-extmod-build), and the following fix up for a more modern kernel
version, I see the following error:
$ make -C /usr/lib/modules/6.19.0-rc7-next-20260129/build M=/tmp/xr_serial modules V=1 W=1
...
# CC [M] xr_serial.o
gcc ...
# cmd_checkdoc xr_serial.o
PYTHONDONTWRITEBYTECODE=1 python3 /usr/lib/modules/6.19.0-rc7-next-20260129/build/tools/docs/kernel-doc -none xr_serial.c
python3: can't open file '/usr/lib/modules/6.19.0-rc7-next-20260129/build/tools/docs/kernel-doc': [Errno 2] No such file or directory
make[3]: *** [/usr/lib/modules/6.19.0-rc7-next-20260129/build/scripts/Makefile.build:287: xr_serial.o] Error 2
If it is not expected that kernel-doc runs for external modules, then
maybe cmd_checkdoc should also be wrapped in a check for KBUILD_EXTMOD?
Cheers,
Nathan
diff --git a/xr_serial.c b/xr_serial.c
index 63a45a2..d4f7d81 100644
--- a/xr_serial.c
+++ b/xr_serial.c
@@ -517,7 +517,7 @@ static void xr_dtr_rts(struct usb_serial_port *port, int on)
xr_tiocmset_port(port, 0, TIOCM_DTR | TIOCM_RTS);
}
-static void xr_break_ctl(struct tty_struct *tty, int break_state)
+static int xr_break_ctl(struct tty_struct *tty, int break_state)
{
struct usb_serial_port *port = tty->driver_data;
struct xr_port_private *port_priv = usb_get_serial_data(port->serial);
@@ -526,7 +526,7 @@ static void xr_break_ctl(struct tty_struct *tty, int break_state)
if (port_priv->model != XR21V141X) {
xr_usb_serial_ctrl_msg(port, USB_CDC_REQ_SEND_BREAK, state,
NULL, 0);
- return;
+ return 0;
}
if (break_state == 0)
@@ -538,6 +538,7 @@ static void xr_break_ctl(struct tty_struct *tty, int break_state)
state == UART_BREAK_OFF ? "off" : "on");
xr_set_reg_uart(port, xr_hal_table[port_priv->model][REG_TX_BREAK],
state);
+ return 0;
}
/* Tx and Rx clock mask values obtained from section 3.3.4 of datasheet */
@@ -645,7 +646,7 @@ static int xr_set_baudrate(struct tty_struct *tty,
static void xr_set_flow_mode(struct tty_struct *tty,
struct usb_serial_port *port,
- struct ktermios *old_termios)
+ const struct ktermios *old_termios)
{
struct xr_port_private *port_priv = usb_get_serial_data(port->serial);
u8 flow, gpio_mode;
@@ -701,7 +702,7 @@ static void xr_set_flow_mode(struct tty_struct *tty,
static void xr_set_termios_cdc(struct tty_struct *tty,
struct usb_serial_port *port,
- struct ktermios *old_termios)
+ const struct ktermios *old_termios)
{
struct ktermios *termios = &tty->termios;
struct usb_cdc_line_coding line = { 0 };
@@ -747,7 +748,7 @@ static void xr_set_termios_cdc(struct tty_struct *tty,
static void xr_set_termios_format_reg(struct tty_struct *tty,
struct usb_serial_port *port,
- struct ktermios *old_termios)
+ const struct ktermios *old_termios)
{
struct xr_port_private *port_priv = usb_get_serial_data(port->serial);
struct ktermios *termios = &tty->termios;
@@ -805,7 +806,7 @@ static void xr_set_termios_format_reg(struct tty_struct *tty,
static void xr_set_termios(struct tty_struct *tty,
struct usb_serial_port *port,
- struct ktermios *old_termios)
+ const struct ktermios *old_termios)
{
struct xr_port_private *port_priv = usb_get_serial_data(port->serial);
On Thu, 29 Jan 2026 23:40:11 -0700 Nathan Chancellor <nathan@kernel.org> wrote: > On Fri, Jan 30, 2026 at 06:30:56AM +0100, Mauro Carvalho Chehab wrote: > > On Thu, 29 Jan 2026 18:11:06 -0700 > > Nathan Chancellor <nathan@kernel.org> wrote: > > > On Fri, Jan 30, 2026 at 01:49:55AM +0800, Rong Zhang wrote: > ... > > > > $ make -C /lib/modules/6.19.0-rc6/build/ M="$(pwd)" modules V=1 W=1 > > > > [...] > > > > make -f /usr/src/linux-headers-6.19.0-rc6/scripts/Makefile.build obj=. need-builtin=1 need-modorder=1 > > > > # CC [M] mod.o > > > > [...] > > > > # cmd_checkdoc mod.o > > > > PYTHONDONTWRITEBYTECODE=1 python3 /usr/src/linux-headers-6.19.0-rc6/scripts/kernel-doc.py -none mod.c > > > > This sounds really weird, as it is trying to run scripts/kernel-doc.py > > instead of tools/docs/kernel-doc. Does the out-of-tree Makefile > > override KERNELDOC variable? The current version contains: > > > > KERNELDOC = $(srctree)/tools/docs/kernel-doc > > > > But somehow it is using the old version before the renames: > > > > KERNELDOC = $(srctree)/scripts/kernel-doc.py > > Well I think based on the "6.19.0-rc6" in the path above, this is > mainline, not -next, so the rename has has not happend there yet. Ah, ok. On your e-mail you mentioned the renaming patch, so I ended assuming that was the case. > > > Btw, I did a very quick test here, using an old OOT project I have > > at github: > > > > https://github.com/mchehab/xr_serial > ... > > It sounds to me that Rong may be using a Makefile on his OOT project > > that was not updated to pick the right kernel-doc tool. > > If I use that project with Rong's original command, the > linux-upstream-headers package from the pacman-pkg target (which uses > install-extmod-build), and the following fix up for a more modern kernel > version, I see the following error: > > $ make -C /usr/lib/modules/6.19.0-rc7-next-20260129/build M=/tmp/xr_serial modules V=1 W=1 > ... > # CC [M] xr_serial.o > gcc ... > # cmd_checkdoc xr_serial.o > PYTHONDONTWRITEBYTECODE=1 python3 /usr/lib/modules/6.19.0-rc7-next-20260129/build/tools/docs/kernel-doc -none xr_serial.c > python3: can't open file '/usr/lib/modules/6.19.0-rc7-next-20260129/build/tools/docs/kernel-doc': [Errno 2] No such file or directory > make[3]: *** [/usr/lib/modules/6.19.0-rc7-next-20260129/build/scripts/Makefile.build:287: xr_serial.o] Error 2 > > If it is not expected that kernel-doc runs for external modules, then > maybe cmd_checkdoc should also be wrapped in a check for KBUILD_EXTMOD? I don't particularly see any reason why running kernel-doc for external modules, as the goal of running it there (outside make htmldocs) is to detect early problems at linux-next and other CIs. On the other hand, I also don't see any problem on encapsulating kernel-doc at the tarball created by install-extmod-build with something like: ifeq ($(KBUILD_EXTMOD),) ifneq ($(KBUILD_EXTRA_WARN),) cmd_checkdoc = PYTHONDONTWRITEBYTECODE=1 $(PYTHON3) $(KERNELDOC) -none $(KDOCFLAGS) \ $(if $(findstring 2, $(KBUILD_EXTRA_WARN)), -Wall) \ $< endif endif at scripts/Makefile.build. So, feel free to add to either one of the approaches: Reviewed-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> That's said, it should be noticed that the DRM subsystem also has some similar code: drivers/gpu/drm/Makefile: PYTHONDONTWRITEBYTECODE=1 $(PYTHON3) $(KERNELDOC) -none $(if $(CONFIG_WERROR)$(CONFIG_DRM_WERROR),-Werror) $<; \ drivers/gpu/drm/i915/Makefile: cmd_checkdoc = PYTHONDONTWRITEBYTECODE=1 $(PYTHON3) $(KERNELDOC) -none -Werror $< drivers/gpu/drm/i915/Makefile: $(KERNELDOC) -none -Werror $<; touch $@ include/drm/Makefile: PYTHONDONTWRITEBYTECODE=1 $(PYTHON3) $(KERNELDOC) -none $(if $(CONFIG_WERROR)$(CONFIG_DRM_WERROR),-Werror) $<; \ scripts/Makefile.build: cmd_checkdoc = PYTHONDONTWRITEBYTECODE=1 $(PYTHON3) $(KERNELDOC) -none $(KDOCFLAGS) \ but I suspect that only scripts/Makefile.build probably need such check. Regards, Mauro
On Fri, Jan 30, 2026 at 09:32:03AM +0100, Mauro Carvalho Chehab wrote: > On Thu, 29 Jan 2026 23:40:11 -0700 > Nathan Chancellor <nathan@kernel.org> wrote: > > > On Fri, Jan 30, 2026 at 06:30:56AM +0100, Mauro Carvalho Chehab wrote: > > > On Thu, 29 Jan 2026 18:11:06 -0700 > > > Nathan Chancellor <nathan@kernel.org> wrote: > > > > On Fri, Jan 30, 2026 at 01:49:55AM +0800, Rong Zhang wrote: > > ... > > > > > $ make -C /lib/modules/6.19.0-rc6/build/ M="$(pwd)" modules V=1 W=1 > > > > > [...] > > > > > make -f /usr/src/linux-headers-6.19.0-rc6/scripts/Makefile.build obj=. need-builtin=1 need-modorder=1 > > > > > # CC [M] mod.o > > > > > [...] > > > > > # cmd_checkdoc mod.o > > > > > PYTHONDONTWRITEBYTECODE=1 python3 /usr/src/linux-headers-6.19.0-rc6/scripts/kernel-doc.py -none mod.c > > > > > > This sounds really weird, as it is trying to run scripts/kernel-doc.py > > > instead of tools/docs/kernel-doc. Does the out-of-tree Makefile > > > override KERNELDOC variable? The current version contains: > > > > > > KERNELDOC = $(srctree)/tools/docs/kernel-doc > > > > > > But somehow it is using the old version before the renames: > > > > > > KERNELDOC = $(srctree)/scripts/kernel-doc.py > > > > Well I think based on the "6.19.0-rc6" in the path above, this is > > mainline, not -next, so the rename has has not happend there yet. > > Ah, ok. On your e-mail you mentioned the renaming patch, so I > ended assuming that was the case. > > > > > > Btw, I did a very quick test here, using an old OOT project I have > > > at github: > > > > > > https://github.com/mchehab/xr_serial > > ... > > > It sounds to me that Rong may be using a Makefile on his OOT project > > > that was not updated to pick the right kernel-doc tool. > > > > If I use that project with Rong's original command, the > > linux-upstream-headers package from the pacman-pkg target (which uses > > install-extmod-build), and the following fix up for a more modern kernel > > version, I see the following error: > > > > $ make -C /usr/lib/modules/6.19.0-rc7-next-20260129/build M=/tmp/xr_serial modules V=1 W=1 > > ... > > # CC [M] xr_serial.o > > gcc ... > > # cmd_checkdoc xr_serial.o > > PYTHONDONTWRITEBYTECODE=1 python3 /usr/lib/modules/6.19.0-rc7-next-20260129/build/tools/docs/kernel-doc -none xr_serial.c > > python3: can't open file '/usr/lib/modules/6.19.0-rc7-next-20260129/build/tools/docs/kernel-doc': [Errno 2] No such file or directory > > make[3]: *** [/usr/lib/modules/6.19.0-rc7-next-20260129/build/scripts/Makefile.build:287: xr_serial.o] Error 2 > > > > If it is not expected that kernel-doc runs for external modules, then > > maybe cmd_checkdoc should also be wrapped in a check for KBUILD_EXTMOD? > > I don't particularly see any reason why running kernel-doc for external > modules, as the goal of running it there (outside make htmldocs) is to > detect early problems at linux-next and other CIs. > > On the other hand, I also don't see any problem on encapsulating > kernel-doc at the tarball created by install-extmod-build with something > like: > > ifeq ($(KBUILD_EXTMOD),) > ifneq ($(KBUILD_EXTRA_WARN),) > cmd_checkdoc = PYTHONDONTWRITEBYTECODE=1 $(PYTHON3) $(KERNELDOC) -none $(KDOCFLAGS) \ > $(if $(findstring 2, $(KBUILD_EXTRA_WARN)), -Wall) \ > $< > endif > endif > > at scripts/Makefile.build. > > > So, feel free to add to either one of the approaches: > > Reviewed-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Thanks everybody for report and analysis! I put Mauro's suggestion into a new patch for kbuild-next: https://lore.kernel.org/linux-kbuild/20260131-run-kernel-doc-only-in-tree-v1-1-93a9c695dfb1@kernel.org/ I plan to send the pull request tonight. > That's said, it should be noticed that the DRM subsystem also has > some similar code: > > drivers/gpu/drm/Makefile: PYTHONDONTWRITEBYTECODE=1 $(PYTHON3) $(KERNELDOC) -none $(if $(CONFIG_WERROR)$(CONFIG_DRM_WERROR),-Werror) $<; \ > drivers/gpu/drm/i915/Makefile: cmd_checkdoc = PYTHONDONTWRITEBYTECODE=1 $(PYTHON3) $(KERNELDOC) -none -Werror $< > drivers/gpu/drm/i915/Makefile: $(KERNELDOC) -none -Werror $<; touch $@ > include/drm/Makefile: PYTHONDONTWRITEBYTECODE=1 $(PYTHON3) $(KERNELDOC) -none $(if $(CONFIG_WERROR)$(CONFIG_DRM_WERROR),-Werror) $<; \ > scripts/Makefile.build: cmd_checkdoc = PYTHONDONTWRITEBYTECODE=1 $(PYTHON3) $(KERNELDOC) -none $(KDOCFLAGS) \ > > but I suspect that only scripts/Makefile.build probably need > such check. yes, I think so too, as the definitions in drm should only take effect on hdrtest target. Kind regards, Nicolas
© 2016 - 2026 Red Hat, Inc.