Remove 31/32-bit s390 Linux support (s390-linux-gnu triplet)

[tiran]

BPO	43179
Nosy	@tiran, @mcepl, @ambv, @stratakis, @glaubitz, @jrtc27
PRs	python/cpython#24534 python/cpython#24624
Files	gcc-s390.txt: GCC macro definitions for Linux on Z in 31 bit mode gcc-s390x.txt: GCC macro definitions for Linux on Z in 64 bit mode

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields: ```python assignee = None closed_at = None created_at = labels = ['interpreter-core', '3.10'] title = 'Remove 31/32-bit s390 Linux support (s390-linux-gnu triplet)' updated_at = user = 'https://github.com/tiran' ``` bugs.python.org fields: ```python activity = actor = 'fweimer' assignee = 'none' closed = False closed_date = None closer = None components = ['Interpreter Core'] creation = creator = 'christian.heimes' dependencies = [] files = ['49817', '49818'] hgrepos = [] issue_num = 43179 keywords = ['patch'] message_count = 56.0 messages = ['386709', '386983', '386984', '386985', '386986', '386996', '386997', '386999', '387000', '387002', '387003', '387004', '387005', '387006', '387008', '387009', '387010', '387019', '387021', '387022', '387025', '387038', '387093', '387094', '387095', '387096', '387097', '387114', '387130', '387132', '387156', '387161', '387162', '387165', '387167', '387176', '387202', '387203', '387227', '387255', '387257', '387258', '387261', '387262', '387263', '387265', '387456', '387457', '387458', '387459', '387460', '387465', '389103', '389104', '389887', '412198'] nosy_count = 9.0 nosy_names = ['christian.heimes', 'mcepl', 'Arfrever', 'lukasz.langa', 'fweimer', 'David.Edelsohn', 'cstratak', 'glaubitz', 'jrtc27'] pr_nums = ['24534', '24624'] priority = 'normal' resolution = None stage = 'patch review' status = 'open' superseder = None type = None url = 'https://bugs.python.org/issue43179' versions = ['Python 3.10'] ```

[tiran]

configure.ac contains triplet definitions for s390 and s390x mainframes. While s390x (Linux on IBM Z) is still widely supported, s390 is not. s390 was released in 1990 and discontinued in 1998, https://en.wikipedia.org/wiki/IBM_System/390

Ariadne Conill from Alpine pointed out that:

Linux has not supported booting on traditional 31-bit s390 since
Linux 4.1 in 2015. If you can't boot s390 (not s390x) with a modern
kernel, it is absurd to demand that other projects support s390.

https://github.com/pyca/cryptography/issues/5771#issuecomment-775872483

I propose to remove check for __s390__ from configure.ac and configure.

We might also want to remove __alpha, __hppa, and __m68k__ at a later point. DEC hasn't been around for a long time.

[dcc71577-db0c-41a9-99d8-b23abe84b9a2]

I'm a Debian Developer and maintainer for multiple Debian Ports architectures.

Please don't remove support for Alpha, HPPA, m68k, ia64, PowerPC, SuperH, SPARC as we're still maintaining these in Debian.

Here are the latest build results for Python3.9 in Debian with build logs for all these architectures:

https://buildd.debian.org/status/package.php?p=python3.9&suite=sid

There are no issues reported and we heavily rely on Python.

[dcc71577-db0c-41a9-99d8-b23abe84b9a2]

And, FWIW, I generally don't quite understand what the problem with old triplet definitions in configure.ac are. I assume they don't hurt anyone, do they?

You never know what usecases your users have and as long as a code snippet doesn't interfere with other code, I don't see little point in removing it.

[tiran]

It's about setting expectations. For some users, the presence of a platform triplet implies support for a platform.

[dcc71577-db0c-41a9-99d8-b23abe84b9a2]

That's an argument I have personally never heard before and I have been dealing with a lot of architecture support in many packages.

FWIW, lots of upstream projects have targets which are officially supported and others which are there but not supported and that was never really a problem.

As long as the architectures are being maintained in the Linux kernel, GCC, binutils and glibc, they can be considered usable and maintained.

The m68k architecture for example has a very active and large community due to the popularity of retro computing. This has lead to efforts which will soon bring Rust support to M68k and the Amiga.

I therefore don't really understand what you gain when you make it harder for downstreams to use Python.

[tiran]

That's an argument I have personally never heard before and I have been dealing with a lot of architecture support in many packages.

I opened this ticket after a user told me that they grepped the source code of Python, found the string "s390", and concluded that s390 is still supported by us.

This ticket is really just about s390. I said that we *might want to remove other platform at a *later point. For now I don't mind to keep them. We could also put unsupported platforms behind a --enable-unsupported-platforms guard. The option would allow you to compile on retro platforms and serve as indicator that the platform is not supported by us.

[vstinner]

I propose to remove check for __s390__ from configure.ac and configure.

I don't see a big benefit of removing a few lines of configure.ac. It's not like it's a big maintenance burden.

It's about setting expectations. For some users, the presence of a platform triplet implies support for a platform.

I maintain https://pythondev.readthedocs.io/platforms.html : unofficial list of platforms and C compilateurs supported by Python, and the different kinds of support levels (supported, best effort, not supported).

[vstinner]

Does AIX support the s390 architecture?

[dcc71577-db0c-41a9-99d8-b23abe84b9a2]

I opened this ticket after a user told me that they grepped the source code of Python, found the string "s390", and concluded that s390 is still supported by us.

Because one user was surprised by a few lines in configure.ac, the conclusion is to remove support for that architecture?

That's a very odd justification.

If it really just affects configure.ac, I don't really see a point in removing them. Even in OpenJDK we keep such unofficial architectures in configure.ac (with my OpenJDK upstream maintainer hat on).

[tiran]

Does AIX support the s390 architecture?

The platform triplet is s390-linux-gnu, not AIX.

Because one user was surprised by a few lines in configure.ac, the conclusion is to remove support for that architecture?

You are misinterpreting my words. My initial posting explains that the hardware platform is no longer supported by any of our supported operating systems. I want to make it obvious that the platform has been dropped half a decade ago.

[vstinner]

I checked buildbots, we only have s390x workers (SLES, Debian, Fedora, RHEL7, RHEL8):

    ("s390x SLES", "edelsohn-sles-z", UnixBuild, STABLE),
    ("s390x Debian", "edelsohn-debian-z", UnixBuild, STABLE),
    ("s390x Fedora", "edelsohn-fedora-z", UnixBuild, STABLE),
    ("s390x Fedora Refleaks", "edelsohn-fedora-z", UnixRefleakBuild, STABLE),
    ("s390x Fedora Clang", "edelsohn-fedora-z", ClangUnixBuild, STABLE),
    ("s390x Fedora Clang Installed", "edelsohn-fedora-z", ClangUnixInstalledBuild, STABLE),
    ("s390x Fedora LTO", "edelsohn-fedora-z", LTONonDebugUnixBuild, STABLE),
    ("s390x Fedora LTO + PGO", "edelsohn-fedora-z", LTOPGONonDebugBuild, STABLE),
    ("s390x RHEL7", "edelsohn-rhel-z", UnixBuild, STABLE),
    ("s390x RHEL7 Refleaks", "edelsohn-rhel-z", UnixRefleakBuild, STABLE),
    ("s390x RHEL7 LTO", "edelsohn-rhel-z", LTONonDebugUnixBuild, STABLE),
    ("s390x RHEL7 LTO + PGO", "edelsohn-rhel-z", LTOPGONonDebugBuild, STABLE),
    ("s390x RHEL8", "edelsohn-rhel8-z", UnixBuild, STABLE),
    ("s390x RHEL8 Refleaks", "edelsohn-rhel8-z", UnixRefleakBuild, STABLE),
    ("s390x RHEL8 LTO", "edelsohn-rhel8-z", LTONonDebugUnixBuild, STABLE),
    ("s390x RHEL8 LTO + PGO", "edelsohn-rhel8-z", LTOPGONonDebugBuild, STABLE),

There is no s390 worker running, so I would not say that we still support this platform.

Since 2010, there were 5 commits (all made by me ;-) to fix tests) mentioning "s390" but all of them are about the 64-bit s390x arch, not the 32-bit arch.

[vstinner]

I created PR 24534 "Drop 32-bit Linux s390 platform support".

We might also want to remove __alpha, __hppa, and __m68k__ at a later point. DEC hasn't been around for a long time.

I would prefer to have one ticket per platform support removal.

[dcc71577-db0c-41a9-99d8-b23abe84b9a2]

s390 is a 31-bit platform, not a 32-bit platform.

I also don't see what this change achieves other than making the use of Python 3.10 on s390 harder.

It's not like the removal of support for non-threaded builds which actually saved quite some code:

https://github.com/python/cpython/commit/a6a4dc816d68df04a7d592e0b6af8c7ecc4d4344

[dcc71577-db0c-41a9-99d8-b23abe84b9a2]

I want to make it obvious that the platform has been dropped half a decade ago.

That's a political statement, not a technical one.

The change has zero functional impact on the other targets. It just makes the use of Python in a potential s390 VM harder.

s390 packages are still being built for SUSE Linux Enterprise 12 which is still actively supported. I assume the same applies to RHEL LTS releases but I can't verify that as I have no insight into RedHat's internal build system.

[tiran]

The guidelines for platform support are explained in PEP-11 (https://www.python.org/dev/peps/pep-0011/#supporting-platforms). We don't support platforms unless we have maintainers and CI (builtbots) in place for the platform.

[ambv]

+1 from me. Whatever few users s390 still has, they can keep using Python 3.9 which is 5 years newer than the latest kernel they can use.

Moving forward, s390 will be unambiguously unsupported as we cannot test against this platform. Unless we get a buildbot provided for this purpose, as well as somebody willing to fix broken builds on that buildbot long-term, it is what it is.

[dcc71577-db0c-41a9-99d8-b23abe84b9a2]

Moving forward, s390 will be unambiguously unsupported as we cannot test against this platform. Unless we get a buildbot provided for this purpose, as well as somebody willing to fix broken builds on that buildbot long-term, it is what it is.

There is no s390-specifc code in Python in the first place, is there?

[b9c72c32-828e-41b6-8a7e-aac13397383a]

This has nothing to do with AIX.

This conversation should include Charalampos Stratakis, but I don't see him as an option for Nosy.

It probably is easy to add a s390 31-bit build to one of the buildbots.

[vstinner]

s390 is a 31-bit platform, not a 32-bit platform.

ARM64 only uses 48 bits for the address, but it uses 64-bit CPU words. Usually, we refer to an architecture by its CPU word, 32 or 64 bits. s390 uses 32-bit CPU words, no?

The Wikipedia article says:

"ESA/390 is arguably a 32-bit architecture; as with System/360, System/370, 370-XA, and ESA/370, the general-purpose registers are 32 bits long, and the arithmetic instructions support 32-bit arithmetic. Only byte-addressable real memory (Central Storage) and Virtual Storage addressing is limited to 31 bits."

s390 packages are still being built for SUSE Linux Enterprise 12 which is still actively supported. I assume the same applies to RHEL LTS releases but I can't verify that as I have no insight into RedHat's internal build system.

Red Hat maintains Fedora and RHEL, none is supporting s390, but both support s390x:

• https://fedoraproject.org/wiki/Architectures
• https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/considerations_in_adopting_rhel_8/architectures_considerations-in-adopting-rhel-8

Note: The correct name is Red Hat ;-)

[vstinner]

Łukasz Langa:

+1 from me. Whatever few users s390 still has, they can keep using Python 3.9 which is 5 years newer than the latest kernel they can use.

Nowadays, it became trivial to maintain downstream patches. It is easy to fork the Python Git repository and put your patches on top of it. Here it's only a matter of doing the maintenance upstream or not.

Moving forward, s390 will be unambiguously unsupported as we cannot test against this platform. Unless we get a buildbot provided for this purpose, as well as somebody willing to fix broken builds on that buildbot long-term, it is what it is.

Wait. I would prefer to not have a buildbot worker unless there is a volunteer to fix all s390 specific issues. Otherwise, setting a buildbot worker will not solve any problem. I'm talking about build failures, test failures and issues on the worker directly.

[12c7b821-ad6f-4235-91d8-57b2aacb2dfc]

For RHEL7 which is the older OS that buildbots are still running, only the System Z architecture is supported. From the release notes [0]:

Note that Red Hat Enterprise Linux 7 supports IBM zEnterprise 196 hardware or later; IBM System z10 mainframe systems are no longer supported and will not boot Red Hat Enterprise Linux 7.

Also 32 (31 bits) in this case are only supported through virtualization with older OS's. So IMO it's fine to remove the support.

[0] https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/7.0_release_notes/chap-red_hat_enterprise_linux-7.0_release_notes-architectures

[12c7b821-ad6f-4235-91d8-57b2aacb2dfc]

And to dig a bit further with a semi-official answer.

RHEL4 had standalone support for s390, while since RHEL5+ we've had only multilib support (64 bits kernel and possibility of s390 userspace packages).

RHEL7 that is the oldest currently supported RHEL OS, does have multilib support, meaning that 32 bit (s390) userspace packages are available for s390x booting on 64 bit kernel.

Although a later base python version for RHEL7 will not be shipped as we already have python2.7.5 and python3.8.6 supported there, which already builds for s390 for the aforementioned multilib support.

On Software Collections where we actually sometimes ship later Python versions, we compile only for 64 bits so the removal of the s390 pieces wouldn't pose an issue here.

Hence the only problem I can figure out from my analysis would be for users on s390x who would download the necessary 32bit libraries and dependencies from the repos and use the -m32 CFLAGS and LDFLAGS to get a 32 bits build.

[dcc71577-db0c-41a9-99d8-b23abe84b9a2]

The guidelines for platform support are explained in PEP-11 (https://www.python.org/dev/peps/pep-0011/#supporting-platforms). We don't support platforms unless we have maintainers and CI (builtbots) in place for the platform.

You don't need to support a platform. Just call it unsupported and ignore issues if people report them unless they provide a patch themselves.

FWIW, the Python interpreter has never caused any issues on any platform that we support in Debian. We are regularly building the latest upstream versions of all available Python interpreters thanks to the packaging work of Matthias Klose.

You can view test results any time by going to https://buildd.debian.org/ and searching for "pythonX.Y". So there is actually a CI for release builds.

[dcc71577-db0c-41a9-99d8-b23abe84b9a2]

So IMO it's fine to remove the support.

You are not removing "support". You're just disallowing users to use the Python interpreter - which works perfectly fine on all architectures we have in current and previous releases - on Debian.

A few preprocessor macros plus some lines in a configure.ac aren't something that would qualify as platform support. There is no architecture-specific code and the Python interpreter is highly portable and just works whereever we build it in Debian (and openSUSE).

I would unterstand the reasoning of such a change if there was a swath of users filing bug reports about s390 and you just don't want to deal with that any longer. But that's not the case as far as I can see.

[tiran]

You don't need to support a platform. Just call it unsupported and ignore issues if people report them unless they provide a patch themselves.

This thread is an excellent example why ignoring platforms comes at a cost. It will only get worse when are going to introduce platform and architecture specific code for optimizations and features.

You can view test results any time by going to https://buildd.debian.org/ and searching for "pythonX.Y". So there is actually a CI for release builds.

The site does not list a s390 builder. There is only a s390x builder.

[dcc71577-db0c-41a9-99d8-b23abe84b9a2]

This thread is an excellent example why ignoring platforms comes at a cost. It will only get worse when are going to introduce platform and architecture specific code for optimizations and features.

Which is purely hypothetical at the moment. You are arguing with something that might happen in the future but currently doesn't exist to justify the removal of 5 lines of preprocessor and autoconf "code".

You can still drop these lines in the future _if_ they happen to cause any headache. But that is currently not the case, so there isn't really a burden.

> You can view test results any time by going to https://buildd.debian.org/ and searching for "pythonX.Y". So there is actually a CI for release builds.

The site does not list a s390 builder. There is only a s390x builder.

s390 is being built for SLE-12, for example, on the internal SUSE build system and SLE-12 is still supported. So if a customer wants to use Python 3.10 in a SLE-12 s390 environment, why keep them from doing so?

In my experience some upstream projects make the mistake that they think they always know how users are using their software. But since there is no dedicated feedback channel, you have no means in knowing whether someone is building Python for a given architecture for their custom project. After all, there are source-only distributions like Gentoo, so you don't have to rely on any existing binary builds.

[vstinner]

s390 is being built for SLE-12, for example, on the internal SUSE build system and SLE-12 is still supported. So if a customer wants to use Python 3.10 in a SLE-12 s390 environment, why keep them from doing so?

I don't think that SuSE plans to provide Python 3.10 on SLE-12.

cc @mcepl

[12c7b821-ad6f-4235-91d8-57b2aacb2dfc]

s390 is being built for SLE-12, for example, on the internal SUSE build system and SLE-12 is still supported. So if a customer wants to use Python 3.10 in a SLE-12 s390 environment, why keep them from doing so?

Are you sure about that? It seems SLE-12 support s390x not s390. Maybe it's multilib support in a similar manner that I've mentioned about RHEL7?

[dcc71577-db0c-41a9-99d8-b23abe84b9a2]

Are you sure about that? It seems SLE-12 support s390x not s390. Maybe it's multilib support in a similar manner that I've mentioned about RHEL7?

I work at SUSE. I looked at the internal build system. Debian also still build s390 multilib libraries, i.e. on zelenka.debian.org, I can still install "libc6-s390".

And I still don't understand why you are so keen at keeping people from building Python 3.10 on a certain architecture. You don't gain anything by removing these few lines of codes. But you risk at making someone unhappy who - for whatever reason - builds a 31/32 bit Python 3.10 on an s390x system.

[vstinner]

builds a 31/32 bit Python 3.10 on an s390x system.

What is the use case or benefit of building Python for 32-bit rather than 64-bit?

[dcc71577-db0c-41a9-99d8-b23abe84b9a2]

What is the use case or benefit of building Python for 32-bit rather than 64-bit?

That's not really the question. The question is whether an upstream project should prevent downstreams from using unsupported target configurations and I think the answer to that question is no.

Python is free software (as opposed to just open source software) and one of the key features of free software is that you don't tell your users how they use your software. Open source licenses that limit use cases of software are considered non-free by most if not all Linux distributions for that very reason.

There are valid reasons for preventing your software from being built on certain targets - such as the maintenance burden for architecture-specific code - but none of them apply here. A few lines of autoconf plus some preprocessor macros don't pose any burden and therefore the choice should be in favor of allowing downstreams to build unsupported configurations.

As for providing a CI: Setting up a CI machine for individual upstream projects is not a problem for big corporations like IBM or Intel, but it is certainly a hassle for individual open source developers and hobbyists. And while we (Debian Ports) have provided some CI machines for individual upstream projects such as GCC and LLVM, it should be sufficient for most upstream projects to rely on Debian's buildd infrastructure as we simply don't have the resources that big corporations have.

As for your original question: We still maintain multiple 32-bit ports in Debian, both as official and unofficial releases, and the same is done in other Linux distributions such as Gentoo, openSUSE, Void and others. Lots of hobbyists are pouring a lot of lifeblood and efforts into these ports such as m68k - which has still a surprisingly large user base thanks to retro-computing fans - which is why I am kindly asking you to not put up any obstacles into our ways.

As I said before, the Python interpreter is one of these excellent works of engineering that just work. Other interpreters/compilers such as OpenJDK, Ruby, Go or Rust require much more attention to keep them portable while the Python interpreter has never caused any issues which is something I am very grateful for, in particular given the fact how much other code directly depends on the Python interpreter to work (just think of the many package managers and other system tools written in Python).

So I think I can speak for Debian, Gentoo and many other downstream projects that it is important for many that it stays that way. Of course, that shouldn't Python development keep from moving forward and if the dependence on architecture-dependent code should increase at some point, we can still discuss this issue again and we will be more than happy to help with the porting efforts.

Thank You!

[tiran]

That's not really the question. The question is whether an upstream project should prevent downstreams from using unsupported target configurations and I think the answer to that question is no.

We are not (actively) prevent unsupported target. We are merely removing unused code that we cannot test. Downstream is free to re-apply or maintain additional patches to enable platforms that we don't support. The rules for platform support are explained in PEP-11.

Python is free software (as opposed to just open source software) and one of the key features of free software is that you don't tell your users how they use your software.

Free software doesn't mean free labor. Upstream is free to choose how we spend our time on the project or which patches we accept. For platform support we have (IMHO) reasonable rules for code: Python must compile, work, and pass a sufficient set of its test suite.

While "Python" software is free, the trademark, logo, and rights to the name "Python" are owned by the PSF. The trademark rules are also reasonable. On very few occasions the PSF has asked developers to choose a different name to avoid confusion. For example we asked the developer of a Python 2.8 fork to rename. The fork is now known a Tauthon. Platform compatibility patches are fine.

I see three ways to resolve the dispute:

1) You provide and support CI for s390, we keep the platform triplet. I would be even fine with an unstable buildbot or external CI that builds and runs out test suite regularly. 2) We remove the platform, you maintain downstream patches. The patch in python/cpython#68722 is small and trivial. 3) You contact the Python Steering Council and request a decision. The SC is our elect government and makes final decisions.

I'm going to hold off and delay PR 24534 for at least two weeks to give you time to work on (1) or (3).

[b9c72c32-828e-41b6-8a7e-aac13397383a]

I already am running a Debian s390x buildbot for Python. Someone can adjust the rules for the buildbot to include a 31-bit builder. The Debian buildbot has relatively few builder variants relative to the other s390x targets.

[tiran]

David, this bug is about s390, not s390x. The s390x platform is supported and tested.

[b9c72c32-828e-41b6-8a7e-aac13397383a]

I understand the issue is s390, not s390x. I am offering that there already is an s390x worker, so would it be sufficient to build and test Python in 31 bit mode on that worker as opposed to installing a complete s390 Debian system?

[vstinner]

I understand the issue is s390, not s390x. I am offering that there already is an s390x worker, so would it be sufficient to build and test Python in 31 bit mode on that worker as opposed to installing a complete s390 Debian system?

To get a platform supported by Python, we also need a volunteer to fix issues specific to the 31 bit s390 platform: see PEP-11.

The policy for platform support evolved last years.

[tiran]

David, could you please provide the output of "gcc -dM -E - \< /dev/null" on s390x in 31 bit mode? I'm curious and would like to see the platform constants.

[dcc71577-db0c-41a9-99d8-b23abe84b9a2]

To get a platform supported by Python, we also need a volunteer to fix issues specific to the 31 bit s390 platform: see PEP-11.

You do not need to support every platform. Just allow your users to use them.

If something breaks downstream on a certain platform, distribution maintainers are usually happy to send patches to fix these issues.

I think I can speak for myself here and many of my colleagues at SUSE, my fellow Debian Developers and the guys over at Gentoo who have also lots of talented folk who keep sending fixes for many upstream projects.

My colleague Andreas, for example, has contributed multiple fixes in cpython on m68k:

https://github.com/python/cpython/search?q=Andreas+Schwab&type=commits

[12c7b821-ad6f-4235-91d8-57b2aacb2dfc]

You do not need to support every platform. Just allow your users to use them.

This is kinda missing the point though. For example I've dealt a lot with the CPython codebase (and I'm also one of the Red Hat maintainers for RHEL and Fedora) and although I'm not a core developer, the codebase can be quite intimidating.

I agree that some lines of code do not seem like much but they add up. If noone actually has a use case here, removing them would be the best option overall just from a cognitive perspective.

Now I agree there are hobbyist's and so forth but you present an example, which is irrelevant to this case (m68k is not s390, right?). Do you actually know someone who is actively interested in the usecase of building a 32 bit python on an s390x system? Or do you know someone who owns an s390 system? Maybe someone who sends related fixes to another project?

You claim to speak for other maintainers, yet I'd like to actually hear their position on that. Feel free to add them to the nosy list. If the latest kernel is not even booting, I don't think many people actually care about this arch to at least keep it running.

On the other hand I do think though here that David would be the best person to speak about those use cases, as he is the most experienced here with the s390(x) architecture.

Now from my personal point of view, I don't mind actually keeping the support there, but it will never come up downstream for me, hence it won't affect me as Fedora doesn't build anymore for s390 (and already posted before the case for RHEL).

So again, do you know of this specific usecase, of someone either owning an s390 machine and compiling python, or actually utilizing an s390x machine and using the multilib packages to build a 32 bit python? If so, would you (or they) step up to fix related issues when they come up and assuming a buildbot would be set? Or would you know someone who would?

While your arguments make sense up to a point, claiming that others will step up or saying what others have done for different architectures, doesn't really help your arguments to hold.

[b9c72c32-828e-41b6-8a7e-aac13397383a]

gcc -m31 -dM -E - \< /dev/null

[b9c72c32-828e-41b6-8a7e-aac13397383a]

gcc -dM -E - \< /dev/null

[vstinner]

I'm not sure why people insists to say that it's 31 bit CPU, gcc-s390.txt shows that it uses a classic 32-bit ABI (32-bit long/size_t):

#define __SIZE_MAX__ 0xffffffffUL
#define __LONG_WIDTH__ 32

31-bit is a limit of the address space (memory), not the ALU.

[b9c72c32-828e-41b6-8a7e-aac13397383a]

I am not aware of significant use of 31 bit mode.

But I don't see the benefit of annoying and discouraging users who want to experiment with Python and with Linux on Z in 31 bit mode. Yes, maintenance theoretically is a burden, but there have been no recent issues that were specific to Linux on Z in 31 bit mode. In fact, most of the original Linux on Z support issues that I opened were endianness issues, which aren't ameliorated by removing 31 bit support. As others have expressed, deprecating 31 bit mode only removes the configuration option with no other code simplification.

It seems that it would be better to leave the configuration alone until there actually was an unresolved issue that motivated removal. But I am not aware of any client requirement to continue the support. Leaving the 31 bit configuration unchanged is more about maintaining good will among the volunteers who are interested in the platform.

[b9c72c32-828e-41b6-8a7e-aac13397383a]

Victor: https://en.wikipedia.org/wiki/31-bit_computing :-)

[4fce49d7-9c43-4783-b6f9-bd43eb64c326]

Do you actually know someone who is actively interested in the usecase of building a 32 bit python on an s390x system? Or do you know someone who owns an s390 system?

Well, yes, I have just got it confirmed from our PM, SUSE has living and breathing (and what’s even more interesting, paying) clients using SLE-12 on s390 (i.e., s390x kernel with 32bit libraries). Of course, it doesn’t mean they are eager to run Python 3.10 in such configuration (how do you call such package? python3a so that “python3a” > “python39”?), we will have to evaluate with them what are their plans in the post-36 world with the modern Python there.

[dcc71577-db0c-41a9-99d8-b23abe84b9a2]

But I don't see the benefit of annoying and discouraging users who want to experiment with Python and with Linux on Z in 31 bit mode.

Fully agree.

Yes, maintenance theoretically is a burden, but there have been no recent issues that were specific to Linux on Z in 31 bit mode.

As I have mentioned before, the Python interpreter in general has been very very unproblematic on any platform. The only real issue that I am aware of is that the testsuite can get stuck on machines with a large number of CPUs (we're seeing that on our SPARC T5 in Debian).

In fact, most of the original Linux on Z support issues that I opened were endianness issues, which aren't ameliorated by removing 31 bit support.

And there is still MIPS-BE, PPC-BE, M68k, HPPA among other which are all big-endian.

As others have expressed, deprecating 31 bit mode only removes the configuration option with no other code simplification.

Exactly my point. If it removed a considerable amount of code, I would actually see a point. But just removing a few lines of autoconf or preprocessor code makes no differences from a maintainer's point of view.

It seems that it would be better to leave the configuration alone until there actually was an unresolved issue that motivated removal.

Jepp, fully agree.

But I am not aware of any client requirement to continue the support.

Sure. But free software shouldn't be solely about commercial customers. If someone wants to play with Python on the s390 emulator Hercules, for example, upstream projects shouldn't be keeping them from doing that.

Leaving the 31 bit configuration unchanged is more about maintaining good will among the volunteers who are interested in the platform.

Absolutely. And about not limiting choices when there is no technical argument for it.

[vstinner]

I created a thread on python-dev:

"Move support of legacy platforms/architectures outside Python" https://mail.python.org/archives/list/python-dev@python.org/thread/F5BXISYP7RAINXUMYJSEYG7GCFRFAENF/

[dcc71577-db0c-41a9-99d8-b23abe84b9a2]

"Move support of legacy platforms/architectures outside Python" https://mail.python.org/archives/list/python-dev@python.org/thread/F5BXISYP7RAINXUMYJSEYG7GCFRFAENF/

Motorola 68k isn't a 16-bit architecture, it's a 32-bit architecture.

Also, I am starting to get the feeling that you are trying to escalate a conflict here. None of the code that you are complaining about is hurting anyone. Yet, you think it is important to keep this discussion and ruining my day.

The fact that you take sides for OpenBSD but consider m68k legacy and unmaintained (which isn't correct at all - look at the kernel), shows that you are biased in this discussion.

[dcc71577-db0c-41a9-99d8-b23abe84b9a2]

Oh, and LLVM is currently gaining support M68k which you consider "legacy":

https://reviews.llvm.org/D95315

It might be a good idea to do some research first before making such statements.

[tiran]

For the last time: This ticket is solely about s390 platform. Please stop derailing this ticket with comments about unrelated platforms like m68k. I'm considering your diversion as "sustained disruption of online community discussions", https://www.python.org/psf/conduct/