Message ID | 20241120204125.52644-1-pvorel@suse.cz |
---|---|
State | New |
Headers | show |
Series | [v4,1/2] init/Kconfig: add python3 availability config | expand |
On Fri, Nov 22, 2024 at 1:51 AM Jani Nikula <jani.nikula@linux.intel.com> wrote: > > On Fri, 22 Nov 2024, Masahiro Yamada <masahiroy@kernel.org> wrote: > > Documentation/process/changes.rst > > documents basic tools necessary for building the kernel. > > > > Python3 is listed as "optional" because it is required > > only for some CONFIG options. > > > > If the exact dependency is unclear, it is better to install > > all tools listed in that table. > > I think we're slightly in a limbo with the python build dependency. I > think it got initially merged a bit under the radar. And I don't mean to > imply any ill will here, it just didn't get the attention it maybe > should have. The dependency table got updated afterwards. > > Now, what's the status for more modules depending on python? I for one > would like to use it for i915.ko, but I'm a bit uneasy about it as long > as it's "optional". Conversely, how many more users would we need to > switch the status from "optional" to "required"? > The way I've been looking at it is, for drm gpu drivers, the dependency is only a subset of the py that mesa depends on at build time, and if you are wanting to build the KMD you almost certainly want mesa as well. Maybe the situation is different for kms-only drivers or other subsystems. I may be biased here, but being able to generate code/tables/etc at build time is something that python is very useful for, and has been used to great effect in mesa. And because of mesa's dependency, it seems like a reasonable dependency on the kernel side as well. My only question is how to make the dependency visible in the least confusing way for both users and packagers. BR, -R > > BR, > Jani. > > > -- > Jani Nikula, Intel
> On Thu, Nov 21, 2024 at 10:49 AM Rob Clark <robdclark@gmail.com> wrote: > > On Wed, Nov 20, 2024 at 5:17 PM Petr Vorel <pvorel@suse.cz> wrote: > > > > On Thu, Nov 21, 2024 at 5:41 AM Petr Vorel <pvorel@suse.cz> wrote: > > > > > It will be used in the next commit for DRM_MSM. > > > > > Suggested-by: Rob Clark <robdclark@gmail.com> > > > > > Signed-off-by: Petr Vorel <pvorel@suse.cz> > > > > > --- > > > > > Changes v3->v4: > > > > > * Move definition to the end of the file > > > > I prefer to not check the tool. > > > Ack. > > > > Why don't you install python3? > > > Everybody installs it when it's required, the question is how to inform about > > > the dependency. > > > There build environments are minimal environments: > > > * chroot (e.g. cross compilation) > > > * container > > > These are used by both developers and distros. > > I don't think py3 is an _onerous_ dependency, but it has come up as a > > surprise in minimal distro build environments at least once.. so I'd > > be a fan of surfacing this dependency in a predictable/understandable > > way (ie. I'm in favor of this patchset) > "once" is a keyword here. > "/bin/sh: python3: not found" provides sufficient information > about why the compilation failed, and you know what to do > to fix the problem. > This is good. > If you hide CONFIG_DRM_MSM silently > due to missing python3, you may scratch your head > "why drm/msm was not compiled?". It's not on the list, but still visible in help (via search). > This is worse. I'm ok with this being refused. Yes, it's a trivial thing to find that python3 is not installed. I wasn't sure myself if this is really better. Having something like "requires $(PYTHON3)" would be best solution (e.g. not disable the config, but exit before starting to build), but of course unless this feature is needed for many modules it does not make sense to have it. It's because kernel mostly contains everything (unless languages like python or any other dependency starts to be added). For this reason I like that mconf-cfg.sh warns when missing ncurses devel files (even suggesting package names). Just to explain what was my motivation. CONFIG_DRM_MSM in in arm64 defconfig, thus it will affect anybody who uses the defconfig (any distro will need to add it). It's needed only for Qualcomm arm64 devices only. But only for these devices which are mainlined enough to really use CONFIG_DRM_MSM (many of them aren't in that state). postmarketOS is the distribution which supports Qualcomm. It stores kernel config for each device and devices often have individual maintainer. E.g. 175x "once" :). Kind regards, Petr
On Sat, Nov 23, 2024 at 5:42 AM Petr Vorel <pvorel@suse.cz> wrote: > > > On Thu, Nov 21, 2024 at 10:49 AM Rob Clark <robdclark@gmail.com> wrote: > > > > On Wed, Nov 20, 2024 at 5:17 PM Petr Vorel <pvorel@suse.cz> wrote: > > > > > > On Thu, Nov 21, 2024 at 5:41 AM Petr Vorel <pvorel@suse.cz> wrote: > > > > > > > It will be used in the next commit for DRM_MSM. > > > > > > > Suggested-by: Rob Clark <robdclark@gmail.com> > > > > > > Signed-off-by: Petr Vorel <pvorel@suse.cz> > > > > > > --- > > > > > > Changes v3->v4: > > > > > > * Move definition to the end of the file > > > > > > > I prefer to not check the tool. > > > > > Ack. > > > > > > Why don't you install python3? > > > > > Everybody installs it when it's required, the question is how to inform about > > > > the dependency. > > > > > There build environments are minimal environments: > > > > * chroot (e.g. cross compilation) > > > > * container > > > > > These are used by both developers and distros. > > > > I don't think py3 is an _onerous_ dependency, but it has come up as a > > > surprise in minimal distro build environments at least once.. so I'd > > > be a fan of surfacing this dependency in a predictable/understandable > > > way (ie. I'm in favor of this patchset) > > > > "once" is a keyword here. > > > "/bin/sh: python3: not found" provides sufficient information > > about why the compilation failed, and you know what to do > > to fix the problem. > > This is good. > > > If you hide CONFIG_DRM_MSM silently > > due to missing python3, you may scratch your head > > "why drm/msm was not compiled?". > It's not on the list, but still visible in help (via search). > > > This is worse. > > I'm ok with this being refused. Yes, it's a trivial thing to find that python3 > is not installed. I wasn't sure myself if this is really better. Having > something like "requires $(PYTHON3)" would be best solution (e.g. not disable > the config, but exit before starting to build), but of course unless this > feature is needed for many modules it does not make sense to have it. > It's because kernel mostly contains everything (unless languages like python > or any other dependency starts to be added). For this reason I like that > mconf-cfg.sh warns when missing ncurses devel files (even suggesting package > names). > > Just to explain what was my motivation. CONFIG_DRM_MSM in in arm64 defconfig, > thus it will affect anybody who uses the defconfig (any distro will need to add > it). arch/arm64/configs/defconfig is a multi-platform config. If CONFIG_DRM_MSM exists in arch/arm64/configs/defconfig and if you want to build arm64 defconfig, you need to install all necessary tools for that. > > It's needed only for Qualcomm arm64 devices only. But only for these devices > which are mainlined enough to really use CONFIG_DRM_MSM (many of them aren't in > that state). > > postmarketOS is the distribution which supports Qualcomm. It stores kernel > config for each device and devices often have individual maintainer. E.g. 175x > "once" :). If you do not want to be bothered by unnecessary drivers, you need to disable the relevant CONFIG option. (e.g, scripts/config -d CONFIG_DRM_MSM) This is the standard way we have for many years. -- Best Regards Masahiro Yamada
diff --git a/init/Kconfig b/init/Kconfig index fbd0cb06a50a..c77e45484e81 100644 --- a/init/Kconfig +++ b/init/Kconfig @@ -2047,3 +2047,6 @@ config ARCH_HAS_SYNC_CORE_BEFORE_USERMODE # <asm/syscall_wrapper.h>. config ARCH_HAS_SYSCALL_WRAPPER def_bool n + +config HAVE_PYTHON3 + def_bool $(success,$(PYTHON3) -V)
It will be used in the next commit for DRM_MSM. Suggested-by: Rob Clark <robdclark@gmail.com> Signed-off-by: Petr Vorel <pvorel@suse.cz> --- Changes v3->v4: * Move definition to the end of the file init/Kconfig | 3 +++ 1 file changed, 3 insertions(+)