| Message ID | 20240509-python-version-v1-1-a7dda3a95b5f@linaro.org |
|---|---|
| State | Accepted |
| Commit | 627395716cc36eff127aa81997b535818ab003fa |
| Headers | show |
| Series | docs: document python version used for compilation | expand |
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,
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
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.
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
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
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
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
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.
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
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
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(+) --- base-commit: 704ba27ac55579704ba1289392448b0c66b56258 change-id: 20240509-python-version-a8b6ca2125ff Best regards,