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
