On Fri, Oct 25, 2024, at 10:10, John Paul Adrian Glaubitz wrote:
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.
Changing all system call numbers and a lot of the ioctl
structures definitely makes it a new ABI, regardless of
how much it affects general userspace, and does require a
complete bootstrap of the distro.
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.
Doing it without a migration path seems worse to me,
as this would mean breaking every single existing
installation between two kernels, and making it impossible
to bisect other issues, and breaking the rule #1.
It's probably not necessary to support both user ABIs
in a single kernel image, but a kernel compile-time switch
would seem appropriate.
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.
Understood.
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'm not worried about ancient binaries, and I think a 10 year
transition period like in ARM-EABI or PPC64/ELFv2 would be
fine, but breaking all users from one release to the next
is a clear show-stopper.
Arnd
