Re: Plan needed for switching m68k to 32-bit alignment

[John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>]

Hi Arnd,

On Fri, 2024-10-25 at 09:55 +0000, Arnd Bergmann wrote:
> 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.

I don't actually know whether this would be a completely new ABI
as m68k has supported 32-bit alignment through the "-malign-int"
switch for a long time.

> 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.

I was not talking about maintaining two separate ABIs and I don't
think it makes much sense to keep the old ABI around.

> 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.

The m68k port is already half broken because of the 16-bit
alignment and I have to admit I starting to get tired of
people telling me that switching the default alignment is a
bad idea.

A current example is Python 3.13 which just crashes with the
default alignment but builds just fine with "-malign-int".

I really don't understand why there is such a big resistance of
switching a port over to a different alignment which allegedly
no one is using or maintaining.

Someone made a bad design decision 40 years ago and we're not
allowed to fix that because someone might run an old binary
from the 80ies on a current version of the Linux kernel.

> 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.

Users with very slow hardware and without accelerators aren't
going to run a modern kernel anyway, so this argument is moot.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913