From: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
To: Jani Nikula <jani.nikula@intel.com>
Cc: Jonathan Corbet <corbet@lwn.net>,
Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
Linux Doc Mailing List <linux-doc@vger.kernel.org>,
linux-kernel@vger.kernel.org, workflows@vger.kernel.org,
Akira Yokosawa <akiyks@gmail.com>
Subject: Re: [PATCH v2 3/2] docs: changes: better document Python needs
Date: Mon, 28 Jul 2025 17:33:06 +0200 [thread overview]
Message-ID: <20250728173306.2ab1409a@sal.lan> (raw)
In-Reply-To: <83d12d5293e23c622ae390204fed8fd4453014b1@intel.com>
Em Mon, 28 Jul 2025 12:28:45 +0300
Jani Nikula <jani.nikula@intel.com> escreveu:
> On Thu, 24 Jul 2025, Mauro Carvalho Chehab <mchehab+huawei@kernel.org> wrote:
> > Em Thu, 24 Jul 2025 08:42:59 -0600
> > Jonathan Corbet <corbet@lwn.net> escreveu:
> >
> >> Mauro Carvalho Chehab <mchehab+huawei@kernel.org> writes:
> >>
> >> > Maybe I can place instead CONFIG_DRM_I915_WERROR.
> >>
> >> I've held off on this series on the expectation that a new version would
> >> come. I guess, at this point, it will be a post-merge-window thing?
> >
> > Feel free to postpone. I have already a new version of it here somewhere on
> > my branches, but I had to take some days off. So, I ended not sending you
> > the (probably) final version.
> >
> > I intend to send what I have here during the merge window for you to
> > review and apply post-merge-window.
>
> I think the main questions here are 1) how to handle optional build tool
> dependencies, and 2) whether Python is an optional or required
> dependency.
with regards to (2), besides doc build and kernel-doc --none, there is
at least another place at the building system requiring Python:
scripts/Makefile.vmlinux_o: There, it has:
quiet_cmd_gen_initcalls_lds = GEN $@
cmd_gen_initcalls_lds = \
$(PYTHON3) $(srctree)/scripts/jobserver-exec \
$(PERL) $(real-prereqs) > $@
.tmp_initcalls.lds: $(srctree)/scripts/generate_initcall_order.pl \
vmlinux.a $(KBUILD_VMLINUX_LIBS) FORCE
$(call if_changed,gen_initcalls_lds)
targets := .tmp_initcalls.lds
ifdef CONFIG_LTO_CLANG
initcalls-lds := .tmp_initcalls.lds
endif
Now, I didn't check exactly what conditions trigger
.tmp_initcalls.lds, but there are some places that use
select:
arch/Kconfig: select LTO_CLANG
On a quick look, it sounds that some archs will select this
automatically when built with clang.
I didn't check if other parts of the building system requires it.
In any case, on its current state, I'd say that currently this
is not optional.
> It might be nice to be able to have an actual Kconfig and dependency for
> optional tools. "depends on TOOL_PYTHON" or something. Enable the
> option, and you should have Python.
That would be an option. The question is: is it worth spending
time on it?
> This in turn raises the question for allyesconfig. It's cumbersome
> (though not impossible) to add config options that you actually have to
> enable manually.
IMO it doesn't make sense to manually enable something with *config.
If they depend on Python, be it: for such targets, Python is
mandatory.
>
> The header test stuff really isn't required to actually build the kernel
> or drm, however DRM_MSM does depend on Python for building the driver.
Good to know. It means that, for those *config targets:
arch/arm/configs/imx_v6_v7_defconfig:CONFIG_DRM_MSM=y
arch/arm/configs/multi_v7_defconfig:CONFIG_DRM_MSM=m
arch/arm/configs/qcom_defconfig:CONFIG_DRM_MSM=m
(plus all{mod|yes}config)
Python is mandatory. As multi_v7_defconfig is one of them, we
may assume, that, o practical cases, Python 2.7 or 3.2+ is
mandatory for arm support. The current requirement is:
$ vermin -v --no-tips ./drivers/gpu/drm/msm/registers/gen_header.py
Detecting python files..
Analyzing using 8 processes..
2.7, 3.2 /new_devel/v4l/docs/drivers/gpu/drm/msm/registers/gen_header.py
Minimum required versions: 2.7, 3.2
Heh, looking for files that end with .py at Makefile (not all
Python scripts at the Kernel end with such extension), it seems
that there are more:
grep \\\.py $(git ls-files|grep Makefile|grep -v tools)
Makefile:KERNELDOC = $(srctree)/scripts/kernel-doc.py
Makefile: vmlinux-gdb.py \
Makefile: $(Q)ln -fsn $(abspath $(srctree)/scripts/gdb/vmlinux-gdb.py)
Makefile:compile_commands.json: $(srctree)/scripts/clang-tools/gen_compile_commands.py \
Makefile: cmd_clang_tools = $(PYTHON3) $(srctree)/scripts/clang-tools/run-clang-tools.py $@ $<
drivers/gpu/drm/msm/Makefile: cmd_headergen = mkdir -p $(obj)/generated && $(PYTHON3) $(src)/registers/gen_header.py \
drivers/gpu/drm/msm/Makefile: $(src)/registers/gen_header.py \
drivers/gpu/drm/msm/Makefile: $(src)/registers/gen_header.py \
drivers/tty/vt/Makefile:#GENERATE_UCS_TABLES := 2 # invokes gen_ucs_recompose_table.py with --full
drivers/tty/vt/Makefile:$(obj)/ucs_width_table.h: $(src)/gen_ucs_width_table.py
drivers/tty/vt/Makefile:$(obj)/ucs_recompose_table.h: $(src)/gen_ucs_recompose_table.py
drivers/tty/vt/Makefile:$(obj)/ucs_fallback_table.h: $(src)/gen_ucs_fallback_table.py
rust/Makefile: $(Q)MAKEFLAGS= $(srctree)/scripts/generate_rust_analyzer.py \
scripts/Makefile.lib:MAKE_FIT := $(srctree)/scripts/make_fit.py
scripts/gdb/linux/Makefile:symlinks := $(patsubst $(src)/%,%,$(wildcard $(src)/*.py))
scripts/gdb/linux/Makefile:always-y += constants.py
scripts/gdb/linux/Makefile:$(obj)/constants.py: $(src)/constants.py.in FORCE
scripts/gdb/linux/Makefile:clean-files := *.pyc *.pyo
(that not including tools/*)
Some seem false positives, but on the other hand, looking for tools,
several scripts seem to be executed by non-tools Makefiles. I didn't
check if any of them are written in python, though.
Considering the above, for me it seems that the bus already
departed: there are several cases where Python is required during
build time. So, adding a "depends on TOOL_PYTHON" doesn't seem
to be trivial.
From my side, I don't mind much about that, as this is something
that affects only the Kernel build. I would very much prefer to
have things like config BPF optional.
Regards,
Mauro
next prev parent reply other threads:[~2025-07-28 15:33 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-12 8:13 [PATCH v2 0/2] Restore kernel-doc support for prehistoric Python Mauro Carvalho Chehab
2025-07-12 8:13 ` [PATCH v2 1/2] docs: kernel-doc: emit warnings for ancient versions of Python Mauro Carvalho Chehab
2025-07-12 8:13 ` [PATCH v2 2/2] scripts: kdoc: make it backward-compatible with Python 3.7 Mauro Carvalho Chehab
2025-07-12 8:32 ` [PATCH v2 3/2] docs: changes: better document Python needs Mauro Carvalho Chehab
2025-07-12 16:31 ` Laurent Pinchart
2025-07-12 22:25 ` Mauro Carvalho Chehab
2025-07-13 9:27 ` Laurent Pinchart
2025-07-24 14:42 ` Jonathan Corbet
2025-07-24 17:43 ` Mauro Carvalho Chehab
2025-07-28 9:28 ` Jani Nikula
2025-07-28 15:33 ` Mauro Carvalho Chehab [this message]
2025-07-29 10:45 ` Jani Nikula
2025-07-29 13:44 ` Mauro Carvalho Chehab
2025-07-29 15:04 ` Jani Nikula
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=20250728173306.2ab1409a@sal.lan \
--to=mchehab+huawei@kernel.org \
--cc=akiyks@gmail.com \
--cc=corbet@lwn.net \
--cc=jani.nikula@intel.com \
--cc=laurent.pinchart@ideasonboard.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=workflows@vger.kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.