On Fri, Oct 25, 2024, at 06:48, John Paul Adrian Glaubitz wrote:
Hello,
the m68k port has reached the point where switching the default alignment
from 16-bit to 32-bit is inevitable as the number of packages affected by
alignment issues have become too large. It even includes Python 3.13 these
days.
Since I don't think the situation is getting better by postponing action here
in the future, I suggest that we have a virtual meetup soonish to discuss a
strategy for switching the port over.
Maybe a page could be created either on the Debian or Gentoo Wiki to
draft a design
for switching over. Geert also mentioned that we should use this
transition to clean
up the kernel ABI by removing old syscalls and switch the kernel to
asm-generic which
is why I have included Arnd Bergmann in the CC list.
Please join #gentoo-m68k on Libera if you want to discuss this issue.
Hi Adrian,
I think the idea of using the generic syscall ABI (in particular
the time64-only variant) makes sense if there is going to be a
new ABI, and I can help figure out what needs to be done in the
kernel for that.
The question is really if it's already too late to do it now,
given the scope of the project and the limited developer
resources. Maintaining two ABIs in the kernel and toolchain
longterm is likely going to make things harder, and phasing
out the existing ABI completely will likely take more than
a decade. I expect that this is the same timeframe (mid-2030s)
by which we will be debating the removal of any 32-bit
targets from the kernel, in particular if we also want to
add 128-bit targets.
Examples of other ABI changes we had in the kernel are:
- ARM EABI was added before the architecture became
dominant, and ended up as a success. The structure
alignment differences between OABI and EABI were part of
it, but it was mostly pushed because of Thumb
instruction support, and with a huge investment of
development resources.
- PowerPC ELFv2 was a similar success, this one was driven
by a strong desire to allow little-endian distros, and
again was done with a very significant investment.
- MIPS/n32 and x86/x32 never took off despite the effort
put into them and the advantages for both the ABI and
performance compared to running traditional 32-bit
binaries on 64-bit kernels. As I understand, gentoo
still supports both, so clearly someone likes these, but
from a kernel perspective they still cause us headache
and were clearly a mistake. Attempts to do the same
on powerpc/arm64/riscv64 were rejected for these reasons.
- The big-endian ABIs for arm and arm64 were mostly a
complete failure, having been pushed for by network
SoC makers (Intel IXP mainly) before that industry moved
to little-endian. Adding these made a lot of sense at
the time when big-endian powerpc and mips owned that
market but has since turned into a liability. Nowadays
it's mainly used for regression-testing big-endian mode
on widely available hardware (arm64 VM guests).
Based on those experiences, I think there is a significant
chance that adding a new ABI is going to make things harder
to maintain for both distro and kernel maintainers rather
than easier, regardless of how much better the new ABI is.
I also expect that a lot of users (of m68k kernels) are
never going to get the benefits as they are already stuck on
older userspace because of added bloat in new software
releases. I assume you have better understanding than me
of what m68k hardware is commonly used these days, and
how constrained that is in practice.
Arnd
