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
