[PATCH] docs: document python version used for compilation

[PATCH] docs: document python version used for compilation

[Dmitry Baryshkov]

The drm/msm driver had adopted using Python3 script to generate register
header files instead of shipping pre-generated header files. Document
the minimal Python version supported by the script.

Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
---
 Documentation/process/changes.rst | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/process/changes.rst b/Documentation/process/changes.rst
index 5685d7bfe4d0..8d225a9f65a2 100644
--- a/Documentation/process/changes.rst
+++ b/Documentation/process/changes.rst
@@ -63,6 +63,7 @@ cpio                   any              cpio --version
 GNU tar                1.28             tar --version
 gtags (optional)       6.6.5            gtags --version
 mkimage (optional)     2017.01          mkimage --version
+Python (optional)      3.5.x            python3 --version
 ====================== ===============  ========================================
 
 .. [#f1] Sphinx is needed only to build the Kernel documentation

---
base-commit: 704ba27ac55579704ba1289392448b0c66b56258
change-id: 20240509-python-version-a8b6ca2125ff

Best regards,
-- 
Dmitry Baryshkov <dmitry.baryshkov@linaro.org>

Re: [PATCH] docs: document python version used for compilation

[Jonathan Corbet]

Dmitry Baryshkov <dmitry.baryshkov@linaro.org> writes:

> The drm/msm driver had adopted using Python3 script to generate register
> header files instead of shipping pre-generated header files. Document
> the minimal Python version supported by the script.
>
> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
> ---
>  Documentation/process/changes.rst | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/Documentation/process/changes.rst b/Documentation/process/changes.rst
> index 5685d7bfe4d0..8d225a9f65a2 100644
> --- a/Documentation/process/changes.rst
> +++ b/Documentation/process/changes.rst
> @@ -63,6 +63,7 @@ cpio                   any              cpio --version
>  GNU tar                1.28             tar --version
>  gtags (optional)       6.6.5            gtags --version
>  mkimage (optional)     2017.01          mkimage --version
> +Python (optional)      3.5.x            python3 --version
>  ====================== ===============  ========================================

Is it really optional - can you build the driver without it?

This document needs some help... I'm missing a number of things that are
*not* marked as "optional" (jfsutils, reiserfsprogs, pcmciautils, ppp,
...) and somehow my system works fine :)  It would be nice to document
*why* users might need a specific tool.

But I guess we aren't going to do that now.  I can apply this, but I do
wonder about the "optional" marking.

Thanks,

jon

Re: [PATCH] docs: document python version used for compilation

[Abhinav Kumar]

On 5/9/2024 9:48 AM, Jonathan Corbet wrote:
> Dmitry Baryshkov <dmitry.baryshkov@linaro.org> writes:
> 
>> The drm/msm driver had adopted using Python3 script to generate register
>> header files instead of shipping pre-generated header files. Document
>> the minimal Python version supported by the script.
>>
>> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
>> ---
>>   Documentation/process/changes.rst | 1 +
>>   1 file changed, 1 insertion(+)
>>
>> diff --git a/Documentation/process/changes.rst b/Documentation/process/changes.rst
>> index 5685d7bfe4d0..8d225a9f65a2 100644
>> --- a/Documentation/process/changes.rst
>> +++ b/Documentation/process/changes.rst
>> @@ -63,6 +63,7 @@ cpio                   any              cpio --version
>>   GNU tar                1.28             tar --version
>>   gtags (optional)       6.6.5            gtags --version
>>   mkimage (optional)     2017.01          mkimage --version
>> +Python (optional)      3.5.x            python3 --version
>>   ====================== ===============  ========================================
> 
> Is it really optional - can you build the driver without it?
> 

True, we cannot build the driver now without it. So we should be 
dropping the optional tag.

With that addressed,

Reviewed-by: Abhinav Kumar <quic_abhinavk@quicinc.com>

> This document needs some help... I'm missing a number of things that are
> *not* marked as "optional" (jfsutils, reiserfsprogs, pcmciautils, ppp,
> ...) and somehow my system works fine :)  It would be nice to document
> *why* users might need a specific tool.
> 
> But I guess we aren't going to do that now.  I can apply this, but I do
> wonder about the "optional" marking.
> 
> Thanks,
> 
> jon

Re: [PATCH] docs: document python version used for compilation

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 2230 bytes --]

On Thu May 9, 2024 at 6:48 PM CEST, Jonathan Corbet wrote:
> Dmitry Baryshkov <dmitry.baryshkov@linaro.org> writes:
>
> > The drm/msm driver had adopted using Python3 script to generate register
> > header files instead of shipping pre-generated header files. Document
> > the minimal Python version supported by the script.
> >
> > Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
> > ---
> >  Documentation/process/changes.rst | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/Documentation/process/changes.rst b/Documentation/process/changes.rst
> > index 5685d7bfe4d0..8d225a9f65a2 100644
> > --- a/Documentation/process/changes.rst
> > +++ b/Documentation/process/changes.rst
> > @@ -63,6 +63,7 @@ cpio                   any              cpio --version
> >  GNU tar                1.28             tar --version
> >  gtags (optional)       6.6.5            gtags --version
> >  mkimage (optional)     2017.01          mkimage --version
> > +Python (optional)      3.5.x            python3 --version
> >  ====================== ===============  ========================================
>
> Is it really optional - can you build the driver without it?
>
> This document needs some help... I'm missing a number of things that are
> *not* marked as "optional" (jfsutils, reiserfsprogs, pcmciautils, ppp,
> ...) and somehow my system works fine :)  It would be nice to document
> *why* users might need a specific tool.
>
> But I guess we aren't going to do that now.  I can apply this, but I do
> wonder about the "optional" marking.

I guess it depends a bit on what exactly "optional" implies. It's
optional in the sense that you can easily disable the driver and then
build without Python.

So does "optional" mean that allmodconfig for all platforms builds
without the dependency? Or does it mean some definition of "core" kernel
builds for a set of defined platforms?

Maybe this really needs to be annotated with the exact Kconfig options
that need this. Although that could get out of hands rather quickly. At
some point we may have to list a *lot* of these options.

Alternatively, maybe Kconfig could be taught about build dependencies?

Thierry

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH] docs: document python version used for compilation

[Geert Uytterhoeven]

Hi Thierry,

On Thu, May 30, 2024 at 7:07 PM Thierry Reding <thierry.reding@gmail.com> wrote:
> Alternatively, maybe Kconfig could be taught about build dependencies?

git grep "depends on \$(" -- "*Kconf*"

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH] docs: document python version used for compilation

[Dmitry Baryshkov]

On Fri, May 31, 2024 at 09:33:12AM +0200, Geert Uytterhoeven wrote:
> Hi Thierry,
> 
> On Thu, May 30, 2024 at 7:07 PM Thierry Reding <thierry.reding@gmail.com> wrote:
> > Alternatively, maybe Kconfig could be taught about build dependencies?
> 
> git grep "depends on \$(" -- "*Kconf*"
> 

I'd rather not do that. The driver option disappearing just because the
pythong vesion is incorrect might be misleading to the users. Anyway,
with the Abhinav's patch the issue should be fixed (and I'll take care
not to break it again). Sorry for all the troubles.

-- 
With best wishes
Dmitry

Re: [PATCH] docs: document python version used for compilation

[Thierry Reding]

[-- Attachment #1.1.1: Type: text/plain, Size: 404 bytes --]

On Fri May 31, 2024 at 9:33 AM CEST, Geert Uytterhoeven wrote:
> Hi Thierry,
>
> On Thu, May 30, 2024 at 7:07 PM Thierry Reding <thierry.reding@gmail.com> wrote:
> > Alternatively, maybe Kconfig could be taught about build dependencies?
>
> git grep "depends on \$(" -- "*Kconf*"

Duh... of course there's something like this already. =)

Maybe something like the attached patch?

Thierry

[-- Attachment #1.2: 0001-kbuild-Allow-Kconfig-dependendencies-on-Python.patch --]
[-- Type: text/x-patch, Size: 2658 bytes --]

From 153eaec61513e14f5a7f8f2a998600d07f17bc84 Mon Sep 17 00:00:00 2001
From: Thierry Reding <treding@nvidia.com>
Date: Fri, 31 May 2024 10:51:42 +0200
Subject: [PATCH] kbuild: Allow Kconfig dependendencies on Python

Recently drivers have started depending on Python to generate register
definitions during the build process. In order to prevent such drivers
from breaking builds on systems that don't have Python installed, make
them depend on the minimum required Python version that they need via
Kconfig. If Python is not installed on the system, these drivers will
be automatically disabled.

Signed-off-by: Thierry Reding <treding@nvidia.com>
---
 drivers/gpu/drm/msm/Kconfig |  1 +
 scripts/min-tool-version.sh |  3 +++
 scripts/python-version.sh   | 41 +++++++++++++++++++++++++++++++++++++
 3 files changed, 45 insertions(+)
 create mode 100755 scripts/python-version.sh

diff --git a/drivers/gpu/drm/msm/Kconfig b/drivers/gpu/drm/msm/Kconfig
index 1931ecf73e32..5f7f84de55e4 100644
--- a/drivers/gpu/drm/msm/Kconfig
+++ b/drivers/gpu/drm/msm/Kconfig
@@ -11,6 +11,7 @@ config DRM_MSM
 	depends on QCOM_LLCC || QCOM_LLCC=n
 	depends on QCOM_COMMAND_DB || QCOM_COMMAND_DB=n
 	depends on PM
+	depends on $(success,$(srctree)/scripts/python-version.sh)
 	select IOMMU_IO_PGTABLE
 	select QCOM_MDT_LOADER if ARCH_QCOM
 	select REGULATOR
diff --git a/scripts/min-tool-version.sh b/scripts/min-tool-version.sh
index 91c91201212c..447a3ad4c0bf 100755
--- a/scripts/min-tool-version.sh
+++ b/scripts/min-tool-version.sh
@@ -38,6 +38,9 @@ rustc)
 bindgen)
 	echo 0.65.1
 	;;
+python)
+	echo 3.5.0
+	;;
 *)
 	echo "$1: unknown tool" >&2
 	exit 1
diff --git a/scripts/python-version.sh b/scripts/python-version.sh
new file mode 100755
index 000000000000..c997d40418dc
--- /dev/null
+++ b/scripts/python-version.sh
@@ -0,0 +1,41 @@
+#!/bin/sh
+# SPDX-License-Identifier: GPL-2.0-only
+#
+# Print the Python version in a 5 or 6-digit form.
+# Also, perform the minimum version check.
+
+set -e
+
+PYTHON=${PYTHON:-python}
+
+get_canonical_version()
+{
+	IFS=.
+	set -- $1
+
+	# If the 2nd or 3rd field is missing, fill it with a zero.
+	echo $((10000 * $1 + 100 * ${2:-0} + ${3:-0}))
+}
+
+output=$(LC_ALL=C "$PYTHON" --version)
+
+# Split the line on spaces.
+IFS=' '
+set -- $output
+name=$1
+version=$2
+
+min_tool_version=$(dirname $0)/min-tool-version.sh
+min_version=$($min_tool_version python)
+
+cversion=$(get_canonical_version $version)
+min_version=$(get_canonical_version $min_version)
+
+if [ "$cversion" -lt "$min_version" ]; then
+	echo >&2 "***"
+	echo >&2 "*** Python is too old."
+	echo >&2 "***"
+	exit 1
+fi
+
+echo $name $version
-- 
2.44.0


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH] docs: document python version used for compilation

[Jani Nikula]

On Thu, 09 May 2024, Dmitry Baryshkov <dmitry.baryshkov@linaro.org> wrote:
> The drm/msm driver had adopted using Python3 script to generate register
> header files instead of shipping pre-generated header files. Document
> the minimal Python version supported by the script.
>
> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
> ---
>  Documentation/process/changes.rst | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/Documentation/process/changes.rst b/Documentation/process/changes.rst
> index 5685d7bfe4d0..8d225a9f65a2 100644
> --- a/Documentation/process/changes.rst
> +++ b/Documentation/process/changes.rst
> @@ -63,6 +63,7 @@ cpio                   any              cpio --version
>  GNU tar                1.28             tar --version
>  gtags (optional)       6.6.5            gtags --version
>  mkimage (optional)     2017.01          mkimage --version
> +Python (optional)      3.5.x            python3 --version

Python 3.5 reached end-of-life 3½ years ago [1]. What's the point in
using anything older than the oldest supported version of Python,
i.e. 3.8 at this time?

BR,
Jani.


[1] https://devguide.python.org/versions/



>  ====================== ===============  ========================================
>  
>  .. [#f1] Sphinx is needed only to build the Kernel documentation
>
> ---
> base-commit: 704ba27ac55579704ba1289392448b0c66b56258
> change-id: 20240509-python-version-a8b6ca2125ff
>
> Best regards,

-- 
Jani Nikula, Intel

Re: [PATCH] docs: document python version used for compilation

[Mauro Carvalho Chehab]

Em Fri, 10 May 2024 11:08:38 +0300
Jani Nikula <jani.nikula@intel.com> escreveu:

> On Thu, 09 May 2024, Dmitry Baryshkov <dmitry.baryshkov@linaro.org> wrote:
> > The drm/msm driver had adopted using Python3 script to generate register
> > header files instead of shipping pre-generated header files. Document
> > the minimal Python version supported by the script.
> >
> > Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
> > ---
> >  Documentation/process/changes.rst | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/Documentation/process/changes.rst b/Documentation/process/changes.rst
> > index 5685d7bfe4d0..8d225a9f65a2 100644
> > --- a/Documentation/process/changes.rst
> > +++ b/Documentation/process/changes.rst
> > @@ -63,6 +63,7 @@ cpio                   any              cpio --version
> >  GNU tar                1.28             tar --version
> >  gtags (optional)       6.6.5            gtags --version
> >  mkimage (optional)     2017.01          mkimage --version
> > +Python (optional)      3.5.x            python3 --version  
> 
> Python 3.5 reached end-of-life 3½ years ago [1]. What's the point in
> using anything older than the oldest supported version of Python,
> i.e. 3.8 at this time?

What's the point of breaking compilation with on older distros?
The idea of minimal versions here is to specify the absolute minimum
version that it is required for the build to happen. If 3.5 is
the minimal one, then be it.

-

Now, a criteria is needed to raise the minimal version. IMO, the
minimal version shall be at least the minimal one present on most
used LTS distros that are not EOL.

I would look for at least 4 such distros:

- Debian

  Looking at https://wiki.debian.org/LTS, Debian 10 EOL will be on
  June, 2024.

  Looking at:

	https://distrowatch.com/table.php?distribution=debian

  Debian 10 uses python 3.7.3.

- Looking at Distrowatch for openSUSE Leap 15.5, it uses Python
  3.6.15 and has an EOL schedule for Dec, 2024.

- RHEL 8.9 uses a bigger version than those two - 3.11.5 - again
  looking at Distrowatch to check it.

- SLES 15 SP4 and above uses Python 3.11, according with:
  https://www.suse.com/c/python-3-11-stack-for-suse-linux-enterprise-15/

From the above, IMO kernel shall support building with Python 3.6 
at least until the end of this year.

Regards,
Mauro

Re: [PATCH] docs: document python version used for compilation

[Jani Nikula]

On Fri, 10 May 2024, Mauro Carvalho Chehab <mchehab@kernel.org> wrote:
> Em Fri, 10 May 2024 11:08:38 +0300
> Jani Nikula <jani.nikula@intel.com> escreveu:
>
>> On Thu, 09 May 2024, Dmitry Baryshkov <dmitry.baryshkov@linaro.org> wrote:
>> > The drm/msm driver had adopted using Python3 script to generate register
>> > header files instead of shipping pre-generated header files. Document
>> > the minimal Python version supported by the script.
>> >
>> > Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
>> > ---
>> >  Documentation/process/changes.rst | 1 +
>> >  1 file changed, 1 insertion(+)
>> >
>> > diff --git a/Documentation/process/changes.rst b/Documentation/process/changes.rst
>> > index 5685d7bfe4d0..8d225a9f65a2 100644
>> > --- a/Documentation/process/changes.rst
>> > +++ b/Documentation/process/changes.rst
>> > @@ -63,6 +63,7 @@ cpio                   any              cpio --version
>> >  GNU tar                1.28             tar --version
>> >  gtags (optional)       6.6.5            gtags --version
>> >  mkimage (optional)     2017.01          mkimage --version
>> > +Python (optional)      3.5.x            python3 --version  
>> 
>> Python 3.5 reached end-of-life 3½ years ago [1]. What's the point in
>> using anything older than the oldest supported version of Python,
>> i.e. 3.8 at this time?
>
> What's the point of breaking compilation with on older distros?
> The idea of minimal versions here is to specify the absolute minimum
> version that it is required for the build to happen. If 3.5 is
> the minimal one, then be it.

AFAICT 3.5 was an arbitrary rather than a deliberate choice. We should
at least be aware *why* we'd be sticking to old versions.

Minimum versions here also means sticking to features available in said
versions, for Python just as well as for GCC or any other tool. That's
not zero cost.

I guess there are two angles here too. The absolute minimum version
currently required, and the, uh, maximum the minimum version can be
safely bumped to. Say, you want to use a feature not available in the
current minimum, how far up can you bump the version to?

Could we define and document the criteria (e.g. based on distros as you
suggest below) so we don't have to repeat the discussion?


BR,
Jani.

>
> -
>
> Now, a criteria is needed to raise the minimal version. IMO, the
> minimal version shall be at least the minimal one present on most
> used LTS distros that are not EOL.
>
> I would look for at least 4 such distros:
>
> - Debian
>
>   Looking at https://wiki.debian.org/LTS, Debian 10 EOL will be on
>   June, 2024.
>
>   Looking at:
>
> 	https://distrowatch.com/table.php?distribution=debian
>
>   Debian 10 uses python 3.7.3.
>
> - Looking at Distrowatch for openSUSE Leap 15.5, it uses Python
>   3.6.15 and has an EOL schedule for Dec, 2024.
>
> - RHEL 8.9 uses a bigger version than those two - 3.11.5 - again
>   looking at Distrowatch to check it.
>
> - SLES 15 SP4 and above uses Python 3.11, according with:
>   https://www.suse.com/c/python-3-11-stack-for-suse-linux-enterprise-15/
>
> From the above, IMO kernel shall support building with Python 3.6 
> at least until the end of this year.
>
> Regards,
> Mauro

-- 
Jani Nikula, Intel

Re: [PATCH] docs: document python version used for compilation

[Dmitry Baryshkov]

On Fri, 10 May 2024 at 13:09, Jani Nikula <jani.nikula@intel.com> wrote:
>
> On Fri, 10 May 2024, Mauro Carvalho Chehab <mchehab@kernel.org> wrote:
> > Em Fri, 10 May 2024 11:08:38 +0300
> > Jani Nikula <jani.nikula@intel.com> escreveu:
> >
> >> On Thu, 09 May 2024, Dmitry Baryshkov <dmitry.baryshkov@linaro.org> wrote:
> >> > The drm/msm driver had adopted using Python3 script to generate register
> >> > header files instead of shipping pre-generated header files. Document
> >> > the minimal Python version supported by the script.
> >> >
> >> > Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
> >> > ---
> >> >  Documentation/process/changes.rst | 1 +
> >> >  1 file changed, 1 insertion(+)
> >> >
> >> > diff --git a/Documentation/process/changes.rst b/Documentation/process/changes.rst
> >> > index 5685d7bfe4d0..8d225a9f65a2 100644
> >> > --- a/Documentation/process/changes.rst
> >> > +++ b/Documentation/process/changes.rst
> >> > @@ -63,6 +63,7 @@ cpio                   any              cpio --version
> >> >  GNU tar                1.28             tar --version
> >> >  gtags (optional)       6.6.5            gtags --version
> >> >  mkimage (optional)     2017.01          mkimage --version
> >> > +Python (optional)      3.5.x            python3 --version
> >>
> >> Python 3.5 reached end-of-life 3½ years ago [1]. What's the point in
> >> using anything older than the oldest supported version of Python,
> >> i.e. 3.8 at this time?
> >
> > What's the point of breaking compilation with on older distros?
> > The idea of minimal versions here is to specify the absolute minimum
> > version that it is required for the build to happen. If 3.5 is
> > the minimal one, then be it.
>
> AFAICT 3.5 was an arbitrary rather than a deliberate choice. We should
> at least be aware *why* we'd be sticking to old versions.

From my side, the 3.5 was chosen basing on the previous feedback from
Jon Hunter: https://lore.kernel.org/dri-devel/20240412165407.42163-1-jonathanh@nvidia.com/

After checking distros that I can easily use, I don't think I will be
able to test the script with Python versions earlier than 3.7.3
(Debian oldoldstable).
I can try setting up Debian stretch (old-old-old-stable), which has
Python 3.5 and so cover the needs of Jon.

>
> Minimum versions here also means sticking to features available in said
> versions, for Python just as well as for GCC or any other tool. That's
> not zero cost.
>
> I guess there are two angles here too. The absolute minimum version
> currently required, and the, uh, maximum the minimum version can be
> safely bumped to. Say, you want to use a feature not available in the
> current minimum, how far up can you bump the version to?
>
> Could we define and document the criteria (e.g. based on distros as you
> suggest below) so we don't have to repeat the discussion?
>
>
> BR,
> Jani.
>
> >
> > -
> >
> > Now, a criteria is needed to raise the minimal version. IMO, the
> > minimal version shall be at least the minimal one present on most
> > used LTS distros that are not EOL.
> >
> > I would look for at least 4 such distros:
> >
> > - Debian
> >
> >   Looking at https://wiki.debian.org/LTS, Debian 10 EOL will be on
> >   June, 2024.
> >
> >   Looking at:
> >
> >       https://distrowatch.com/table.php?distribution=debian
> >
> >   Debian 10 uses python 3.7.3.
> >
> > - Looking at Distrowatch for openSUSE Leap 15.5, it uses Python
> >   3.6.15 and has an EOL schedule for Dec, 2024.
> >
> > - RHEL 8.9 uses a bigger version than those two - 3.11.5 - again
> >   looking at Distrowatch to check it.
> >
> > - SLES 15 SP4 and above uses Python 3.11, according with:
> >   https://www.suse.com/c/python-3-11-stack-for-suse-linux-enterprise-15/
> >
> > From the above, IMO kernel shall support building with Python 3.6
> > at least until the end of this year.
> >
> > Regards,
> > Mauro
>
> --
> Jani Nikula, Intel



-- 
With best wishes
Dmitry

Re: [PATCH] docs: document python version used for compilation

[Mauro Carvalho Chehab]

Em Fri, 10 May 2024 13:39:17 +0300
Dmitry Baryshkov <dmitry.baryshkov@linaro.org> escreveu:

> On Fri, 10 May 2024 at 13:09, Jani Nikula <jani.nikula@intel.com> wrote:
> >
> > On Fri, 10 May 2024, Mauro Carvalho Chehab <mchehab@kernel.org> wrote:  
> > > Em Fri, 10 May 2024 11:08:38 +0300
> > > Jani Nikula <jani.nikula@intel.com> escreveu:
> > >  
> > >> On Thu, 09 May 2024, Dmitry Baryshkov <dmitry.baryshkov@linaro.org> wrote:  
> > >> > The drm/msm driver had adopted using Python3 script to generate register
> > >> > header files instead of shipping pre-generated header files. Document
> > >> > the minimal Python version supported by the script.
> > >> >
> > >> > Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
> > >> > ---
> > >> >  Documentation/process/changes.rst | 1 +
> > >> >  1 file changed, 1 insertion(+)
> > >> >
> > >> > diff --git a/Documentation/process/changes.rst b/Documentation/process/changes.rst
> > >> > index 5685d7bfe4d0..8d225a9f65a2 100644
> > >> > --- a/Documentation/process/changes.rst
> > >> > +++ b/Documentation/process/changes.rst
> > >> > @@ -63,6 +63,7 @@ cpio                   any              cpio --version
> > >> >  GNU tar                1.28             tar --version
> > >> >  gtags (optional)       6.6.5            gtags --version
> > >> >  mkimage (optional)     2017.01          mkimage --version
> > >> > +Python (optional)      3.5.x            python3 --version  
> > >>
> > >> Python 3.5 reached end-of-life 3½ years ago [1]. What's the point in
> > >> using anything older than the oldest supported version of Python,
> > >> i.e. 3.8 at this time?  
> > >
> > > What's the point of breaking compilation with on older distros?
> > > The idea of minimal versions here is to specify the absolute minimum
> > > version that it is required for the build to happen. If 3.5 is
> > > the minimal one, then be it.  
> >
> > AFAICT 3.5 was an arbitrary rather than a deliberate choice. We should
> > at least be aware *why* we'd be sticking to old versions.  
> 
> From my side, the 3.5 was chosen basing on the previous feedback from
> Jon Hunter: https://lore.kernel.org/dri-devel/20240412165407.42163-1-jonathanh@nvidia.com/
> 
> After checking distros that I can easily use, I don't think I will be
> able to test the script with Python versions earlier than 3.7.3
> (Debian oldoldstable).
> I can try setting up Debian stretch (old-old-old-stable), which has
> Python 3.5 and so cover the needs of Jon.

Fedora 40 supports version 3.6 and above (plus 2.7):
	https://developer.fedoraproject.org/tech/languages/python/multiple-pythons.html

You could do something similar with Ubuntu/Debian:
	https://askubuntu.com/questions/682869/how-do-i-install-a-different-python-version-using-apt-get

Once an old version is installed, you can enable it with:

	$ python3.6 -m venv v3.6  # create the environment
	$ . v3.6/bin/activate

Then, if needed, install whatever dependencies are needed with pip,
inside the venv (for instance if you want to also test Sphinx, you
can install it there via pip).

I guess it should be possible to use a similar venv procedure with
older versions, but you may need to compile it from the sources if
you don't have binaries available for your distro.

Regards,
Mauro

Re: [PATCH] docs: document python version used for compilation

[Mauro Carvalho Chehab]

Em Fri, 10 May 2024 13:39:17 +0300
Dmitry Baryshkov <dmitry.baryshkov@linaro.org> escreveu:

> On Fri, 10 May 2024 at 13:09, Jani Nikula <jani.nikula@intel.com> wrote:
> >
> > On Fri, 10 May 2024, Mauro Carvalho Chehab <mchehab@kernel.org> wrote:  
> > > Em Fri, 10 May 2024 11:08:38 +0300
> > > Jani Nikula <jani.nikula@intel.com> escreveu:
> > >  
> > >> On Thu, 09 May 2024, Dmitry Baryshkov <dmitry.baryshkov@linaro.org> wrote:  
> > >> > The drm/msm driver had adopted using Python3 script to generate register
> > >> > header files instead of shipping pre-generated header files. Document
> > >> > the minimal Python version supported by the script.
> > >> >
> > >> > Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
> > >> > ---
> > >> >  Documentation/process/changes.rst | 1 +
> > >> >  1 file changed, 1 insertion(+)
> > >> >
> > >> > diff --git a/Documentation/process/changes.rst b/Documentation/process/changes.rst
> > >> > index 5685d7bfe4d0..8d225a9f65a2 100644
> > >> > --- a/Documentation/process/changes.rst
> > >> > +++ b/Documentation/process/changes.rst
> > >> > @@ -63,6 +63,7 @@ cpio                   any              cpio --version
> > >> >  GNU tar                1.28             tar --version
> > >> >  gtags (optional)       6.6.5            gtags --version
> > >> >  mkimage (optional)     2017.01          mkimage --version
> > >> > +Python (optional)      3.5.x            python3 --version  
> > >>
> > >> Python 3.5 reached end-of-life 3½ years ago [1]. What's the point in
> > >> using anything older than the oldest supported version of Python,
> > >> i.e. 3.8 at this time?  
> > >
> > > What's the point of breaking compilation with on older distros?
> > > The idea of minimal versions here is to specify the absolute minimum
> > > version that it is required for the build to happen. If 3.5 is
> > > the minimal one, then be it.  
> >
> > AFAICT 3.5 was an arbitrary rather than a deliberate choice. We should
> > at least be aware *why* we'd be sticking to old versions.  
> 
> From my side, the 3.5 was chosen basing on the previous feedback from
> Jon Hunter: https://lore.kernel.org/dri-devel/20240412165407.42163-1-jonathanh@nvidia.com/

Patch there seems small/simple enough if it is all it takes for 3.5.

Yet, it would be nice to hear from Jon Hunter about the rationale
for 3.5 support (if any).

> > Minimum versions here also means sticking to features available in said
> > versions, for Python just as well as for GCC or any other tool. That's
> > not zero cost.
> >
> > I guess there are two angles here too. The absolute minimum version
> > currently required, and the, uh, maximum the minimum version can be
> > safely bumped to. Say, you want to use a feature not available in the
> > current minimum, how far up can you bump the version to?
> >
> > Could we define and document the criteria (e.g. based on distros as you
> > suggest below) so we don't have to repeat the discussion?

Agreed. While we should not bump version randomly, defining a
criteria about when we should update the requirement sounds a great idea.

For me, the criteria is:

- the minimal version shall be at least the minimal one required for the
  Kernel to build at the most used LTS distros that are not EOL, e. g.: 
  Debian, openSUSE/SUSE, CentOS/RHEL and Ubuntu LTS[1].

[1] In practice, Ubuntu LTS usually has a python version newer than
    Debian LTS, and CentOS versions are identical to RHEL ones, so
    I guess checking for Debian, openSUSE, SUSE and RHEL should be
    enough.

Regards,
Mauro

Re: [PATCH] docs: document python version used for compilation

[Jon Hunter]

On 10/05/2024 12:39, Mauro Carvalho Chehab wrote:
> Em Fri, 10 May 2024 13:39:17 +0300
> Dmitry Baryshkov <dmitry.baryshkov@linaro.org> escreveu:
> 
>> On Fri, 10 May 2024 at 13:09, Jani Nikula <jani.nikula@intel.com> wrote:
>>>
>>> On Fri, 10 May 2024, Mauro Carvalho Chehab <mchehab@kernel.org> wrote:
>>>> Em Fri, 10 May 2024 11:08:38 +0300
>>>> Jani Nikula <jani.nikula@intel.com> escreveu:
>>>>   
>>>>> On Thu, 09 May 2024, Dmitry Baryshkov <dmitry.baryshkov@linaro.org> wrote:
>>>>>> The drm/msm driver had adopted using Python3 script to generate register
>>>>>> header files instead of shipping pre-generated header files. Document
>>>>>> the minimal Python version supported by the script.
>>>>>>
>>>>>> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
>>>>>> ---
>>>>>>   Documentation/process/changes.rst | 1 +
>>>>>>   1 file changed, 1 insertion(+)
>>>>>>
>>>>>> diff --git a/Documentation/process/changes.rst b/Documentation/process/changes.rst
>>>>>> index 5685d7bfe4d0..8d225a9f65a2 100644
>>>>>> --- a/Documentation/process/changes.rst
>>>>>> +++ b/Documentation/process/changes.rst
>>>>>> @@ -63,6 +63,7 @@ cpio                   any              cpio --version
>>>>>>   GNU tar                1.28             tar --version
>>>>>>   gtags (optional)       6.6.5            gtags --version
>>>>>>   mkimage (optional)     2017.01          mkimage --version
>>>>>> +Python (optional)      3.5.x            python3 --version
>>>>>
>>>>> Python 3.5 reached end-of-life 3½ years ago [1]. What's the point in
>>>>> using anything older than the oldest supported version of Python,
>>>>> i.e. 3.8 at this time?
>>>>
>>>> What's the point of breaking compilation with on older distros?
>>>> The idea of minimal versions here is to specify the absolute minimum
>>>> version that it is required for the build to happen. If 3.5 is
>>>> the minimal one, then be it.
>>>
>>> AFAICT 3.5 was an arbitrary rather than a deliberate choice. We should
>>> at least be aware *why* we'd be sticking to old versions.
>>
>>  From my side, the 3.5 was chosen basing on the previous feedback from
>> Jon Hunter: https://lore.kernel.org/dri-devel/20240412165407.42163-1-jonathanh@nvidia.com/
> 
> Patch there seems small/simple enough if it is all it takes for 3.5.
> 
> Yet, it would be nice to hear from Jon Hunter about the rationale
> for 3.5 support (if any).


We just have some legacy builders for legacy Tegra devices that are 
still using python 3.5. I will request that these are updated but these 
are not machines that I own and so may take some time.

>>> Minimum versions here also means sticking to features available in said
>>> versions, for Python just as well as for GCC or any other tool. That's
>>> not zero cost.
>>>
>>> I guess there are two angles here too. The absolute minimum version
>>> currently required, and the, uh, maximum the minimum version can be
>>> safely bumped to. Say, you want to use a feature not available in the
>>> current minimum, how far up can you bump the version to?
>>>
>>> Could we define and document the criteria (e.g. based on distros as you
>>> suggest below) so we don't have to repeat the discussion?
> 
> Agreed. While we should not bump version randomly, defining a
> criteria about when we should update the requirement sounds a great idea.
> 
> For me, the criteria is:
> 
> - the minimal version shall be at least the minimal one required for the
>    Kernel to build at the most used LTS distros that are not EOL, e. g.:
>    Debian, openSUSE/SUSE, CentOS/RHEL and Ubuntu LTS[1].
> 
> [1] In practice, Ubuntu LTS usually has a python version newer than
>      Debian LTS, and CentOS versions are identical to RHEL ones, so
>      I guess checking for Debian, openSUSE, SUSE and RHEL should be
>      enough.


Adding Stefan from SUSE because Stefan also reported a similar issue 
[0]. Note that subject of this email is incorrect and should be python 
3.6 and not 2.6 :-)

Jon

[0] https://lore.kernel.org/all/20240118123752.bl3qss3qbbxgvpdk@suse.de/
-- 
nvpublic

Re: [PATCH] docs: document python version used for compilation

[Rob Clark]

On Fri, May 10, 2024 at 3:09 AM Jani Nikula <jani.nikula@intel.com> wrote:
>
> On Fri, 10 May 2024, Mauro Carvalho Chehab <mchehab@kernel.org> wrote:
> > Em Fri, 10 May 2024 11:08:38 +0300
> > Jani Nikula <jani.nikula@intel.com> escreveu:
> >
> >> On Thu, 09 May 2024, Dmitry Baryshkov <dmitry.baryshkov@linaro.org> wrote:
> >> > The drm/msm driver had adopted using Python3 script to generate register
> >> > header files instead of shipping pre-generated header files. Document
> >> > the minimal Python version supported by the script.
> >> >
> >> > Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
> >> > ---
> >> >  Documentation/process/changes.rst | 1 +
> >> >  1 file changed, 1 insertion(+)
> >> >
> >> > diff --git a/Documentation/process/changes.rst b/Documentation/process/changes.rst
> >> > index 5685d7bfe4d0..8d225a9f65a2 100644
> >> > --- a/Documentation/process/changes.rst
> >> > +++ b/Documentation/process/changes.rst
> >> > @@ -63,6 +63,7 @@ cpio                   any              cpio --version
> >> >  GNU tar                1.28             tar --version
> >> >  gtags (optional)       6.6.5            gtags --version
> >> >  mkimage (optional)     2017.01          mkimage --version
> >> > +Python (optional)      3.5.x            python3 --version
> >>
> >> Python 3.5 reached end-of-life 3½ years ago [1]. What's the point in
> >> using anything older than the oldest supported version of Python,
> >> i.e. 3.8 at this time?
> >
> > What's the point of breaking compilation with on older distros?
> > The idea of minimal versions here is to specify the absolute minimum
> > version that it is required for the build to happen. If 3.5 is
> > the minimal one, then be it.
>
> AFAICT 3.5 was an arbitrary rather than a deliberate choice. We should
> at least be aware *why* we'd be sticking to old versions.
>
> Minimum versions here also means sticking to features available in said
> versions, for Python just as well as for GCC or any other tool. That's
> not zero cost.

At this point, the cost to having a lower minimum version is pretty
small, so I'm not worrying too much about it.

Maybe once kernel developers discover mako, and start generating more
at build time, we'll have to re-evaluate. ;-)

BR,
-R

> I guess there are two angles here too. The absolute minimum version
> currently required, and the, uh, maximum the minimum version can be
> safely bumped to. Say, you want to use a feature not available in the
> current minimum, how far up can you bump the version to?
>
> Could we define and document the criteria (e.g. based on distros as you
> suggest below) so we don't have to repeat the discussion?
>
>
> BR,
> Jani.
>
> >
> > -
> >
> > Now, a criteria is needed to raise the minimal version. IMO, the
> > minimal version shall be at least the minimal one present on most
> > used LTS distros that are not EOL.
> >
> > I would look for at least 4 such distros:
> >
> > - Debian
> >
> >   Looking at https://wiki.debian.org/LTS, Debian 10 EOL will be on
> >   June, 2024.
> >
> >   Looking at:
> >
> >       https://distrowatch.com/table.php?distribution=debian
> >
> >   Debian 10 uses python 3.7.3.
> >
> > - Looking at Distrowatch for openSUSE Leap 15.5, it uses Python
> >   3.6.15 and has an EOL schedule for Dec, 2024.
> >
> > - RHEL 8.9 uses a bigger version than those two - 3.11.5 - again
> >   looking at Distrowatch to check it.
> >
> > - SLES 15 SP4 and above uses Python 3.11, according with:
> >   https://www.suse.com/c/python-3-11-stack-for-suse-linux-enterprise-15/
> >
> > From the above, IMO kernel shall support building with Python 3.6
> > at least until the end of this year.
> >
> > Regards,
> > Mauro
>
> --
> Jani Nikula, Intel

Re: [PATCH] docs: document python version used for compilation

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 2730 bytes --]

On Fri May 10, 2024 at 10:04 PM CEST, Rob Clark wrote:
> On Fri, May 10, 2024 at 3:09 AM Jani Nikula <jani.nikula@intel.com> wrote:
> >
> > On Fri, 10 May 2024, Mauro Carvalho Chehab <mchehab@kernel.org> wrote:
> > > Em Fri, 10 May 2024 11:08:38 +0300
> > > Jani Nikula <jani.nikula@intel.com> escreveu:
> > >
> > >> On Thu, 09 May 2024, Dmitry Baryshkov <dmitry.baryshkov@linaro.org> wrote:
> > >> > The drm/msm driver had adopted using Python3 script to generate register
> > >> > header files instead of shipping pre-generated header files. Document
> > >> > the minimal Python version supported by the script.
> > >> >
> > >> > Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
> > >> > ---
> > >> >  Documentation/process/changes.rst | 1 +
> > >> >  1 file changed, 1 insertion(+)
> > >> >
> > >> > diff --git a/Documentation/process/changes.rst b/Documentation/process/changes.rst
> > >> > index 5685d7bfe4d0..8d225a9f65a2 100644
> > >> > --- a/Documentation/process/changes.rst
> > >> > +++ b/Documentation/process/changes.rst
> > >> > @@ -63,6 +63,7 @@ cpio                   any              cpio --version
> > >> >  GNU tar                1.28             tar --version
> > >> >  gtags (optional)       6.6.5            gtags --version
> > >> >  mkimage (optional)     2017.01          mkimage --version
> > >> > +Python (optional)      3.5.x            python3 --version
> > >>
> > >> Python 3.5 reached end-of-life 3½ years ago [1]. What's the point in
> > >> using anything older than the oldest supported version of Python,
> > >> i.e. 3.8 at this time?
> > >
> > > What's the point of breaking compilation with on older distros?
> > > The idea of minimal versions here is to specify the absolute minimum
> > > version that it is required for the build to happen. If 3.5 is
> > > the minimal one, then be it.
> >
> > AFAICT 3.5 was an arbitrary rather than a deliberate choice. We should
> > at least be aware *why* we'd be sticking to old versions.
> >
> > Minimum versions here also means sticking to features available in said
> > versions, for Python just as well as for GCC or any other tool. That's
> > not zero cost.
>
> At this point, the cost to having a lower minimum version is pretty
> small, so I'm not worrying too much about it.
>
> Maybe once kernel developers discover mako, and start generating more
> at build time, we'll have to re-evaluate. ;-)

You're making an interesting point. Does the build dependency here
denote Python (& standard library) or do we assume that if people have
Python installed that they can also install arbitrary extra packages?
Would a Mako dependency need to be explicitly mentioned here?

Thierry

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]