Re: Tuple and changes for m68k with -malign-int

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

Hi Geert,

On Tue, 2025-06-17 at 09:02 +0200, Geert Uytterhoeven wrote:
> On Wed, 21 May 2025 at 04:15, John Klos <john@klos.com> wrote:
> > Should Linux maintain a 32 bit platform that has alignment issues because
> > programmers make bad assumptions?
> 
> Linux (the kernel) does maintain it, and bug fixes are backported
> to stable trees.  The upstream kernel (outside the arch/m68k dir)
> has no problem fixing whatever alignment issues that pop up.

This might change in the future when Rust code becomes more dominant in the kernel.

What's going to happen when Rust code becomes mandatory in key parts of the kernel
and then we're unable to build it because we insisted on keeping the 2 byte ABI?

> > Your argument is that ABI breakage is death, and that projects and the
> > world are better when we tell people to fix their broken code.
> 
> "we don't break user space" is the #1 rule in the kernel[1].

Except when we do: https://lwn.net/Articles/605607/ ;-)

> > I agree that ABI breakage is a huge hurdle. At the same time, the ABI will
> > change to fix 32 bit time. Is there any good reason to NOT switch to 32
> > bit alignment at the same time the time changes are made? I can't think of
> > any reason.
> > 
> > So can we all agree that there's no reason to not change alignment when
> > the time changes are done?
> 
> According to Andeas, here is no change to be made for 64-bit time_t[2].

That's not the question to ask though but rather whether the shift to 64-bit
time_t changed the ABI and according to the analysis made at Debian, it did [1].

Adrian

> [1] https://wiki.debian.org/ReleaseGoals/64bit-time

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