Plan needed for switching m68k to 32-bit alignment

[John Paul Adrian Glaubitz]

Hello,

the m68k port has reached the point where switching the default alignment
from 16-bit to 32-bit is inevitable as the number of packages affected by
alignment issues have become too large. It even includes Python 3.13 these
days.

Since I don't think the situation is getting better by postponing action here
in the future, I suggest that we have a virtual meetup soonish to discuss a
strategy for switching the port over.

Maybe a page could be created either on the Debian or Gentoo Wiki to draft a design
for switching over. Geert also mentioned that we should use this transition to clean
up the kernel ABI by removing old syscalls and switch the kernel to asm-generic which
is why I have included Arnd Bergmann in the CC list.

Please join #gentoo-m68k on Libera if you want to discuss this issue.

Adrian

[John Paul Adrian Glaubitz]

Post by John Paul Adrian Glaubitz
the m68k port has reached the point where switching the default
alignment from 16-bit to 32-bit is inevitable as the number of packages
affected by alignment issues have become too large. It even includes
Python 3.13 these days.

Are there any bug reports you could link to, in support of the "too large"
claim?

The following packages require 32-bit alignment:

- mold
- LLVM
- gccgo
- Qt5 (several packages affected)
- Qt6 (several packages affected)
- OpenJDK (all versions)
- Python >= 3.13
- Rust

Those are the most important projects from the tip of my head, but they are already
the biggest blockers. There is no chance that the upstream maintainers will adjust
their packages for 16-bit alignment, so these will be forever broken on m68k if we
don't switch.

I understand that this might be a painful transition, but I don't see any other way
to keep the m68k port alive in the foreseeable future unless we fix this problem
which keeps blocking the port.

You can see how the Debian m68k port has been falling behind because of the alignment
issues in these statistics: Loading Image...

Adrian

[Finn Thain]

Post by John Paul Adrian Glaubitz

Post by John Paul Adrian Glaubitz
the m68k port has reached the point where switching the default
alignment from 16-bit to 32-bit is inevitable as the number of
packages affected by alignment issues have become too large. It even
includes Python 3.13 these days.

Are there any bug reports you could link to, in support of the "too
large" claim?

- mold
- LLVM
- gccgo
- Qt5 (several packages affected)
- Qt6 (several packages affected)
- OpenJDK (all versions)
- Python >= 3.13
- Rust

That seems to imply that someone requires that those packages are ported.
But without a bug report from such a user, to say the package is broken or
missing, one must question the real requirement.

Post by John Paul Adrian Glaubitz
Those are the most important projects from the tip of my head, but they
are already the biggest blockers. There is no chance that the upstream
maintainers will adjust their packages for 16-bit alignment, so these
will be forever broken on m68k if we don't switch.

I'm curious to see such a refusal in context, presumably as a result of
patch review, in an upstream project bug tracker.

I'm not actually expecting to see good patches refused by core projects
like Python. (Note that MicroPython is available for commercially active
CPUs like the PIC16 family, which are 8-bit processors with 16-bit address
bus.)

If upstream QT or Java developers decide that their software is "not for
us", they may well have a point. Those packages are not installed on my
m68k systems, FWIW.

OTOH, as I've said before, if upstream developers (like Arnd) are looking
ahead to 128-bit platforms then they will be paying attention to alignment
rules. They should be inclined to favour explicit struct definitions over
implicit alignment, don't you think?

Post by John Paul Adrian Glaubitz
I understand that this might be a painful transition, but I don't see
any other way to keep the m68k port alive in the foreseeable future
unless we fix this problem which keeps blocking the port.
You can see how the Debian m68k port has been falling behind because of
https://buildd.debian.org/stats/graph-ports-big.png

I could imagine a viable transition to a new ABI driven by widespread user
demand or involvement. But not by distro stats or maintainer preference.

Absent the right conditions, perhaps it is best focus limited porter and
developer effort on patching only those packages that are really required.

[Thorsten Glaser]

Post by Finn Thain

Post by John Paul Adrian Glaubitz
- mold
- LLVM
- gccgo
- Qt5 (several packages affected)
- Qt6 (several packages affected)
- OpenJDK (all versions)
- Python >=3D 3.13
- Rust

That seems to imply that someone requires that those packages are ported.

Yes, we do. Rust especially is killing the entire FOSS ecosystem.

These all are conditio sine qua n=C5=8Dn when it comes to continuing
Linux/m68k, as a whole.

Post by Finn Thain
Absent the right conditions, perhaps it is best focus limited porter and
developer effort on patching only those packages that are really required.

I tried my hand at Qt5. About 20 man-hours in I essentially gave up,
and that was without even getting to something I could put to a
compile and runtime test.

=E2=80=9CNatural=E2=80=9D alignment of data types has essentially become a =
requirement
these days, and m68k is the only true outlyer (i386 could in theory, but
the Unix psABI designers were sensible enough to not do it).

bye,
//mirabilos
--=20
<igli> exceptions: a truly awful implementation of quite a nice idea.
<igli> just about the worst way you could do something like that, afaic.
<igli> it's like anti-design. <mirabilos> that too=E2=80=A6 may I quote yo=
u on that?
<igli> sure, tho i doubt anyone will listen ;)

[Finn Thain]

Post by Thorsten Glaser

Post by Finn Thain
That seems to imply that someone requires that those packages are ported.

Yes, we do. Rust especially is killing the entire FOSS ecosystem.
These all are conditio sine qua nōn when it comes to continuing
Linux/m68k, as a whole.

I think that's overstating the case. Alternatives to rust are available
and will be for the foreseeable future. Most notably,
https://safecpp.org/draft.html

I agree with your sentiment though, in that rust generally gets a lot of
funding and hype. Even if the Rust Foundation doesn't care about
supporting the backend for m68k, there is still a way for non-commercially
viable platforms to collaborate. In particular,
https://gcc.gnu.org/wiki/RustFrontEnd

Post by Thorsten Glaser

Post by Finn Thain
Absent the right conditions, perhaps it is best focus limited porter and
developer effort on patching only those packages that are really required.

I tried my hand at Qt5. About 20 man-hours in I essentially gave up,
and that was without even getting to something I could put to a
compile and runtime test.

I take your point about the amount of effort required (and the lack of
resources). The answer may be to share the work better by enabling more
collaboration.

It appears that NetBSD/m68k has naturally aligned ints. Perhaps you could
look at adding kernel support for their ABI, and get access to Qt and LLVM
that way, without impacting the existing ABI and its ecosystem.

BTW, it has long annoyed me that two different 68k Mac bootloaders exist,
one each for Linux and NetBSD, which are duplicated effort, and have
different sets of bugs. To my mind, this is another good opportunity to
collaborate and avoid wasted developer effort (perhaps by dual licensing).

Post by Thorsten Glaser
“Natural” alignment of data types has essentially become a requirement
these days, and m68k is the only true outlyer (i386 could in theory, but
the Unix psABI designers were sensible enough to not do it).

I expect alignment assumptions like that will end up putting more
platforms in the same predicament in future. "Natural" alignment is
meaningless in the context of portable data structures, as they exist
without reference to any particular integer unit. It is because your
struct patches improve portability that I'd expect those patches to remain
acceptable upstream.

Q. What is the size of this struct, assuming baa.b is naturally aligned?

struct baa {
int a;
long long b;
};

[Thorsten Glaser]

Post by Thorsten Glaser

That seems to imply that someone requires that those packages are=20
ported.

=20
Yes, we do. Rust especially is killing the entire FOSS ecosystem.
=20
These all are conditio sine qua n=C5=8Dn when it comes to continuing
Linux/m68k, as a whole.

I think that's overstating the case. Alternatives to rust are available=20
and will be for the foreseeable future. Most notably,=20

That=E2=80=99s not the point. Google, for example, are aggressively funding
people to throw away perfectly working code and rewrite it in rust,
or to at least add rust to projects. librsvg has been such a case for
some time already, python-cryptography is, but now we=E2=80=99re losing eve=
n
freetype (!!!) and, possibly, even the Linux kernel.

https://gcc.gnu.org/wiki/RustFrontEnd

That=E2=80=99s assuming it can build the same stuff the same way so it can
be used in packaging.

I expect alignment assumptions like that will end up putting more=20
platforms in the same predicament in future.

No, all the other platforms use natural alignment.

"Natural" alignment is meaningless in the context of portable data
structures, as they exist without reference to any particular integer

Yeah, but in practice, all we have is ILP32 and LP64; the Windows=C2=AE
world has LLP64 in addition. And natural alignment just means that
all the data types=E2=80=99 alignment is their size. (Which kind of makes
sense, so you can read them without getting an unalignment trap on
SPARC or so.)

Q. What is the size of this struct, assuming baa.b is naturally aligned?
struct baa {
int a;
long long b;
};

For ILP32, LP64 and LLP64, it=E2=80=99s 4 (a) + 4 (padding) + 8 (b) =3D 16 =
chars.
More importantly, and relevant for Qt, struct baa is also 8-byte
aligned, and malloc(3) results are usually 8=E2=80=91 or even 16-byte align=
ed.

bye,
//mirabilos
--=20
Gestern Nacht ist mein IRC-Netzwerk explodiert. Ich hatte nicht damit
gerechnet, darum bin ich blutverschmiert=E2=80=A6 wer konnte ahnen, da=C3=
=9F SIE so
reagier=E2=80=99n=E2=80=A6 gestern Nacht ist mein IRC-Netzwerk explodiert~~=
~
=09(as of 2021-06-15 The MirOS Project temporarily reconvenes on OFTC)

[Finn Thain]

Post by Finn Thain
https://gcc.gnu.org/wiki/RustFrontEnd

That’s assuming it can build the same stuff the same way so it can be
used in packaging.

Not an assumption. I simply pointed out an opportunity for collaboration,
because I see the primary problem facing the m68k port is a lack of
resources.

Post by Finn Thain
I expect alignment assumptions like that will end up putting more
platforms in the same predicament in future.

No, all the other platforms use natural alignment.

Post by Finn Thain
"Natural" alignment is meaningless in the context of portable data
structures, as they exist without reference to any particular integer

Yeah, but in practice, all we have is ILP32 and LP64;

... for now.

the Windows® world has LLP64 in addition. And natural alignment just
means that all the data types’ alignment is their size. (Which kind of
makes sense, so you can read them without getting an unalignment trap on
SPARC or so.)

That would mean __alignof__(foo.b) == sizeof(foo.b) but that's not the
case on my Linux/i686 system. 4 != 8:

struct baa {
int a;
long long b;
} foo;

Post by Finn Thain
Q. What is the size of this struct, assuming baa.b is naturally aligned?
struct baa {
int a;
long long b;
};

For ILP32, LP64 and LLP64, it’s 4 (a) + 4 (padding) + 8 (b) = 16 chars.

So natural alignment is portable if you first assume a data model. But the
struct definition itself is not portable, since it doesn't specify a data
model.

More importantly, and relevant for Qt, struct baa is also 8-byte
aligned...

If the struct itself is not naturally aligned, it too will eventually
break someone's assumption of natural alignment.

[Thorsten Glaser]

That would mean __alignof__(foo.b) =3D=3D sizeof(foo.b) but that's not the
struct baa {
int a;
long long b;
} foo;

That struct is just 12 bytes for you then?

That=E2=80=99s possible on i386 but almost nowhere else, and has multiple
penalties on i386 even (cacheline split, loss of atomicity, merging
of accesses, possible cross-page split,=C2=A0=E2=80=A6).

Of course, in this case, the software author ought to have made the
padding explicit or, better, sorted the struct members. But if all
did that we wouldn=E2=80=99t have this problem.

Post by Thorsten Glaser
More importantly, and relevant for Qt, struct baa is also 8-byte
aligned...

If the struct itself is not naturally aligned, it too will eventually
break someone's assumption of natural alignment.

No, structs are not naturally aligned but aligned to the max() of
the alignment of its members. Natural alignment is only applied to
primitive types.

bye,
//mirabilos
--=20
If Harry Potter gets a splitting headache in his scar
when he=E2=80=99s near Tom Riddle (aka Voldemort),
does Tom get pain in the arse when Harry is near him?
=09-- me, wondering why it=E2=80=99s not Jerry Potter=E2=80=A6=E2=80=A6=E2=
=80=A6

[Finn Thain]

Post by Thorsten Glaser

Post by Finn Thain
That would mean __alignof__(foo.b) == sizeof(foo.b) but that's not the
struct baa {
int a;
long long b;
} foo;

That struct is just 12 bytes for you then?

Right. i686 and m68k agree on that.

Post by Thorsten Glaser
That’s possible on i386 but almost nowhere else, and has multiple
penalties on i386 even (cacheline split, loss of atomicity, merging
of accesses, possible cross-page split, 
).

Well, the GCC manual says the Power architecture also has ABI variants
with differing alignment rules.

https://gcc.gnu.org/onlinedocs/gcc-14.2.0/gcc/RS_002f6000-and-PowerPC-Options.html#index-malign-natural
https://gcc.gnu.org/onlinedocs/gcc-14.2.0/gcc/x86-Options.html#index-malign-data-1
https://gcc.gnu.org/onlinedocs/gcc-14.2.0/gcc/x86-Options.html#index-malign-double

Post by Thorsten Glaser
Of course, in this case, the software author ought to have made the
padding explicit or, better, sorted the struct members. But if all did
that we wouldn’t have this problem.

Right. And I don't think the problem is going to go away. One solution
that is sometimes raised is better tooling. I'm not sure how that would
work. Perhaps a better solution would be language changes to allow a
struct definition to be qualified with an explicit data model.

Post by Thorsten Glaser

Post by Finn Thain

Post by Thorsten Glaser
More importantly, and relevant for Qt, struct baa is also 8-byte
aligned...

If the struct itself is not naturally aligned, it too will eventually
break someone's assumption of natural alignment.

No, structs are not naturally aligned but aligned to the max() of the
alignment of its members. Natural alignment is only applied to primitive
types.

Makes sense.

[Thorsten Glaser]

Post by Finn Thain
Right. And I don't think the problem is going to go away. One solution
that is sometimes raised is better tooling. I'm not sure how that would

No. You don=E2=80=99t understand the problem: applications are being
written that require natural alignment for at least 32-bit and
smaller quantities, some possibly for all quantities even. We
need these applications to work, and we cannot redesign them
(it=E2=80=99s common for them to store flags in the lowest pointer bits
and do other awful things).

Could you please, if you cannot believe it yourself, accept the
word of those actually doing the porting that it is direly needed
in the current Linux ecosystem. Thank you.

Post by Finn Thain

Post by Thorsten Glaser
That struct is just 12 bytes for you then?

Right. i686 and m68k agree on that.

The other ones that have misaligned 'long long' variables are
arc
arm (OABI only)
csky
microblaze
nios2
openrisc
superh
i386

Okaaay. So, all =E2=80=9Cold=E2=80=9D platforms or with low distro support.
For Debian, we have superh and i386, out of these. It is
entirely possible that Qt et al. can work with this, but
these all have natural alignment for quantities =E2=89=A4 32 bits.

Does Gentoo support more of them? Debian used to have arm
OABI, but that=E2=80=99s ages ago. I know things like OpenADK support
them, but that is very chiefly embedded.

The 32-bit architectures that use a natural 8-byte
alignment are
arm (EABI)
parisc
mips
powerpc
riscv
s390
sparc
xtensa

That=E2=80=99s majoritily represented in Debian. And ideally, we=E2=80=99d
use that for all new architectures.

I have a feeling that GCC=E2=80=99s -malign-int will only push us
into the former. I have no idea whether it=E2=80=99s feasible to
also change GCC for this; that will probably depend on both
the other =E2=80=9Cwhat parts of the toolchain need changing=E2=80=9D and
whether GCC can be switched with little effort.

bye,
//mirabilos
--=20
22:20=E2=8E=9C<asarch> The crazy that persists in his craziness becomes a m=
aster
22:21=E2=8E=9C<asarch> And the distance between the craziness and geniality=
is
only measured by the success 18:35=E2=8E=9C<asarch> "Psychotics are consist=
ently
inconsistent. The essence of sanity is to be inconsistently inconsistent

[Finn Thain]

... You don’t understand the problem: applications are being written
that require natural alignment for at least 32-bit and smaller
quantities, some possibly for all quantities even. We need these
applications to work, and we cannot redesign them (it’s common for them
to store flags in the lowest pointer bits and do other awful things).
Could you please, if you cannot believe it yourself, accept the word of
those actually doing the porting that it is direly needed in the current
Linux ecosystem. Thank you.

Do I misunderstand or disbelieve? Or have you forgotten what I wrote two
days ago?

You talk about "applications ... being written". Well, two days ago I
mentioned several groups of applications: (1) core packages that accept
alignment patches, (2) packages whose developers shouldn't worry about
small systems anyway, and (3) packags I am concerned about i.e. the ones
actually required by Debian/m68k users (which will presumably lead to
disto bug reports, if they didn't already -- hence my question about bug
reports which remains unanswered).

For Debian, we have superh and i386, out of these.

Is your concern merely for Debian's package archive stats?

What interests me is portability and code reuse in general. That is the
basis on which I would send alignment patches to upstream projects.

[John Paul Adrian Glaubitz]

Post by Finn Thain
You talk about "applications ... being written". Well, two days ago I
mentioned several groups of applications: (1) core packages that accept
alignment patches, (2) packages whose developers shouldn't worry about
small systems anyway, and (3) packags I am concerned about i.e. the ones
actually required by Debian/m68k users (which will presumably lead to
disto bug reports, if they didn't already -- hence my question about bug
reports which remains unanswered).

As I said before, it's about (transitive) build dependencies and the fact
that more and more packages are being rewritten in Rust.

Here is the current top of the list of packages that won't build on m68k
because of the 2-byte alignment issue:

2814 cargo:m68k
900 ghc:m68k
261 gccgo-14:m68k
241 libqt5core5a:m68k
181 architecture-is-64-bit:m68k
117 libglib2.0-0:m68k
81 libcompiler-libs-ocaml-dev-0a396:m68k
81 golang-go:m68k
71 wx3.2-headers:m68k
57 qt6-base-dev:m68k
57 python3:m68k
46 libamd2:m68k

Are you going to fix these for me?

Post by Finn Thain

Post by Thorsten Glaser
For Debian, we have superh and i386, out of these.

Is your concern merely for Debian's package archive stats?

It's not about stats, it's about reverse dependencies.

And, to be honest, I'm started to get tired of this discussion. If there is not
going to be an agreement here, I will either drop the m68k port from Debian or
use the brute-force method with Chewi's patch.

I don't have the energy anymore to justify myself regarding this anymore.

Post by Finn Thain
What interests me is portability and code reuse in general. That is the
basis on which I would send alignment patches to upstream projects.

Upstream projects do not take patches which fix code on m68k. They don't care.

Adrian

[Finn Thain]

Post by John Paul Adrian Glaubitz

Post by Finn Thain
You talk about "applications ... being written". Well, two days ago I
mentioned several groups of applications: (1) core packages that
accept alignment patches, (2) packages whose developers shouldn't
worry about small systems anyway, and (3) packags I am concerned about
i.e. the ones actually required by Debian/m68k users (which will
presumably lead to disto bug reports, if they didn't already -- hence
my question about bug reports which remains unanswered).

As I said before, it's about (transitive) build dependencies and the
fact that more and more packages are being rewritten in Rust.
Here is the current top of the list of packages that won't build on m68k
2814 cargo:m68k
900 ghc:m68k
261 gccgo-14:m68k
241 libqt5core5a:m68k
181 architecture-is-64-bit:m68k
117 libglib2.0-0:m68k
81 libcompiler-libs-ocaml-dev-0a396:m68k
81 golang-go:m68k
71 wx3.2-headers:m68k
57 qt6-base-dev:m68k
57 python3:m68k
46 libamd2:m68k
Are you going to fix these for me?

Are you the only user?

Seriously though, thanks for providing data. Now, if you would link to the
upstream refusals for CPython and golang, I'll do what I can to help.

[John Paul Adrian Glaubitz]

Post by Finn Thain

Post by John Paul Adrian Glaubitz
Here is the current top of the list of packages that won't build on m68k
2814 cargo:m68k
900 ghc:m68k
261 gccgo-14:m68k
241 libqt5core5a:m68k
181 architecture-is-64-bit:m68k
117 libglib2.0-0:m68k
81 libcompiler-libs-ocaml-dev-0a396:m68k
81 golang-go:m68k
71 wx3.2-headers:m68k
57 qt6-base-dev:m68k
57 python3:m68k
46 libamd2:m68k
Are you going to fix these for me?

Are you the only user?

I am the one who does all the work on Debian/m68k.

Post by Finn Thain
Seriously though, thanks for providing data. Now, if you would link to the
upstream refusals for CPython and golang, I'll do what I can to help.

I honestly don't have to justify myself towards you. I will use the Christmas
holidays to make a decision. I will either drop the m68k port from Debian or
just perform a forced switch.

I don't care anymore what you're posting here. You're just wasting my time.

Adrian

[John Paul Adrian Glaubitz]

Post by Finn Thain
Right. And I don't think the problem is going to go away. One solution
that is sometimes raised is better tooling. I'm not sure how that would

No. You don’t understand the problem: applications are being
written that require natural alignment for at least 32-bit and
smaller quantities, some possibly for all quantities even. We
need these applications to work, and we cannot redesign them
(it’s common for them to store flags in the lowest pointer bits
and do other awful things).

Yep, that's exactly the problem. Plus, the maintainers of 99% of the upstream
projects don't care about the alignment peculiarities of the Linux/m68k port.

Could you please, if you cannot believe it yourself, accept the
word of those actually doing the porting that it is direly needed
in the current Linux ecosystem. Thank you.

Agreed 100%.

Post by Finn Thain

Post by Thorsten Glaser
That struct is just 12 bytes for you then?

Right. i686 and m68k agree on that.

The other ones that have misaligned 'long long' variables are
arc
arm (OABI only)
csky
microblaze
nios2
openrisc
superh
i386

Okaaay. So, all “old” platforms or with low distro support.
For Debian, we have superh and i386, out of these. It is
entirely possible that Qt et al. can work with this, but
these all have natural alignment for quantities ≤ 32 bits.

I'm not aware of any serious issues with alignment on i386.

i386 was the original target for 90% of the software in Debian, so if
there are issues, developers have already addressed them.

Does Gentoo support more of them? Debian used to have arm
OABI, but that’s ages ago. I know things like OpenADK support
them, but that is very chiefly embedded.

Currently, Gentoo supports i386 out of that list.

The 32-bit architectures that use a natural 8-byte
alignment are
arm (EABI)
parisc
mips
powerpc
riscv
s390
sparc
xtensa

That’s majoritily represented in Debian. And ideally, we’d
use that for all new architectures.
I have a feeling that GCC’s -malign-int will only push us
into the former. I have no idea whether it’s feasible to
also change GCC for this; that will probably depend on both
the other “what parts of the toolchain need changing” and
whether GCC can be switched with little effort.

Did you see how Chewi implemented 32-bit alignment? He actually didn't

https://marc.info/?l=glibc-help&m=169303990426196&w=2

Adrian

[Finn Thain]

Post by John Paul Adrian Glaubitz

For Debian, we have superh and i386, out of these. It is entirely
possible that Qt et al. can work with this, but these all have natural
alignment for quantities ≀ 32 bits.

I'm not aware of any serious issues with alignment on i386.
i386 was the original target for 90% of the software in Debian, so if
there are issues, developers have already addressed them.

And they did so without needing a new ABI...

[John Paul Adrian Glaubitz]

Post by Finn Thain

Post by John Paul Adrian Glaubitz

For Debian, we have superh and i386, out of these. It is entirely
possible that Qt et al. can work with this, but these all have natural
alignment for quantities ≤ 32 bits.

I'm not aware of any serious issues with alignment on i386.
i386 was the original target for 90% of the software in Debian, so if
there are issues, developers have already addressed them.

And they did so without needing a new ABI...

Because on i386, the original ABI designers didn't make the mistake to enforce
an unnatural alignment.

Honestly, what exactly do you expect to achieve with messages like this?

If you want me to just drop the port, then just say it.

Adrian

[John Paul Adrian Glaubitz]

Hi Arnd,

Post by Finn Thain

Post by Thorsten Glaser

Post by Finn Thain
That would mean __alignof__(foo.b) == sizeof(foo.b) but that's not the
struct baa {
int a;
long long b;
} foo;

That struct is just 12 bytes for you then?

Right. i686 and m68k agree on that.

The other ones that have misaligned 'long long' variables are
arc
arm (OABI only)
csky
microblaze
nios2
openrisc
superh
i386
The 32-bit architectures that use a natural 8-byte
alignment are
arm (EABI)
parisc
mips
powerpc
riscv
s390
sparc
xtensa
m68k is the only architecture supported by linux-6.x that
does 2-byte alignment, otherwise the two seem to be equally
common.

Another useful data point. This is the kind of discussion I had hoped for!

Thanks a lot!

Adrian

[John Paul Adrian Glaubitz]

Post by Finn Thain
Right. And I don't think the problem is going to go away. One solution
that is sometimes raised is better tooling. I'm not sure how that would
work. Perhaps a better solution would be language changes to allow a
struct definition to be qualified with an explicit data model.

This is a pure academic discussion and not leading anywhere.

Adrian

[Geert Uytterhoeven]

Post by Finn Thain

Post by Thorsten Glaser

Post by Finn Thain
That would mean __alignof__(foo.b) == sizeof(foo.b) but that's not the
struct baa {
int a;
long long b;
} foo;

That struct is just 12 bytes for you then?

Right. i686 and m68k agree on that.

On i686 (i.e. gcc -m32 on amd64):

__alignof__(long long) = 8

but

sizeof(struct baa) = 12
__alignof__(struct baa) = 4

???
Isn't the alignment of a struct the largest alignment of any of its members?

Gr{oetje,eeting}s,

Geert

[Finn Thain]

Post by Geert Uytterhoeven

Post by Finn Thain

Post by Thorsten Glaser

Post by Finn Thain
That would mean __alignof__(foo.b) == sizeof(foo.b) but that's not the
struct baa {
int a;
long long b;
} foo;

That struct is just 12 bytes for you then?

Right. i686 and m68k agree on that.

__alignof__(long long) = 8
but
sizeof(struct baa) = 12
__alignof__(struct baa) = 4
???

My i686 compiler agrees with your compiler. Whereas on Linux/m68k,
__alignof__(struct baa) == 2. On NetBSD/m68k I get,

sizeof(struct baa) == 16
__alignof__(long long) == 8
__alignof__(struct baa) == 8

Post by Geert Uytterhoeven
Isn't the alignment of a struct the largest alignment of any of its members?

Sometimes...

[Thorsten Glaser]

Post by Finn Thain
On NetBSD/m68k I get,
sizeof(struct baa) =3D=3D 16
__alignof__(long long) =3D=3D 8
__alignof__(struct baa) =3D=3D 8

That makes sense.

Post by Finn Thain

Isn't the alignment of a struct the largest alignment of any of its memb=

ers?

Post by Finn Thain
Sometimes...

I think I have a rough idea why i386 is weird here.
It famously can misalign, and it probably loads the
members as two separate dwords, being a 32-bit CPU,
and does not offer atomics for it, and so the initial
psABI decided to do that. Or something. If it helps,
it=E2=80=99s just as weird on MirBSD/i386, where this was no
deliberate decision.


***@fish:~ $ ./a.out
int s=3D4 a=3D4
llong s=3D8 a=3D8
baa s=3D12 a=3D4
baa.a s=3D4 a=3D4 o=3D0
baa.b s=3D8 a=3D4 o=3D4

vs.

(pbuild22802-bookworm/i386)***@cafe:/tmp# ./a.out
int s=3D4 a=3D4
llong s=3D8 a=3D8
baa s=3D12 a=3D4
baa.a s=3D4 a=3D4 o=3D0
baa.b s=3D8 a=3D4 o=3D4

vs. (Linux/amd64)

***@x61p:~ $ ./a.out
int s=3D4 a=3D4
llong s=3D8 a=3D8
baa s=3D16 a=3D8
baa.a s=3D4 a=3D4 o=3D0
baa.b s=3D8 a=3D8 o=3D8


But we certainly need to avoid following the other special
case and rather design the post-switch ABI so that it is
as easily handled as any other new ILP32 ABI for another
architecture, when we change it already anyway.

Two questions:

=E2=93=90 if Clang+LLVM doesn=E2=80=99t know -malign-int anyway, and if its
capability to output code for m68k is experimental to
n=C5=8Dnexistent right now, do we even need to take it into
account? Perhaps changing it to always use the new one is good.

=E2=93=91 what does NetBSD do to get the result (considering that
-malign-int supposedly only changes int to 4), patch GCC?

Of particular interest are a couple definitions in=E2=80=A6
https://gcc.gnu.org/git/?p=3Dgcc.git;a=3Dblob;f=3Dgcc/config/m68k/netbsd-el=
f.h;h=3D3d2043bbe7087ac58f0d2c4336734f7a37bba02f;hb=3DHEAD#l269
=E2=80=A6 versus the arch defaults in:
https://gcc.gnu.org/git/?p=3Dgcc.git;a=3Dblob;f=3Dgcc/config/m68k/m68k.h;h=
=3D0d57199714361ff9ed7f92ef28e36f71aee326b3;hb=3DHEAD#l290

With a bit of luck this means that raising BIGGEST_ALIGNMENT
is sufficient to give us 8-octet-aligned doubles and long doubles.
Then we =E2=80=9Cjust=E2=80=9D need to raise the other definitions that ind=
icate
16-bit alignment to 32. (TARGET_SHORT is -mshort is I16LP32 and
so doesn=E2=80=99t need consideration for Linux/m68k.)

I=E2=80=99m not sure anything needs to have 128-bit alignment that won=E2=
=80=99t
explicitly specify that via attributes.

bye,
//mirabilos
--=20
Yay for having to rewrite other people's Bash scripts because bash
suddenly stopped supporting the bash extensions they make use of
=09-- Tonnerre Lombard in #nosec

[Thorsten Glaser]

Forgot=E2=80=A6
struct baa {
=09int a;
=09long long b;
};

#include <stddef.h>
#include <stdio.h>

int main(void) {
=09struct baa stct;

#define t(w,s) printf("%s\ts=3D%u\ta=3D%u\n", #w, \
=09 (unsigned)sizeof(s), (unsigned)__alignof__(s))
#define o(w,m) printf("%s\ts=3D%u\ta=3D%u\to=3D%u\n", #w, \
=09 (unsigned)sizeof(stct.m), (unsigned)__alignof__(stct.m), \
=09 (unsigned)offsetof(struct baa, m))
=09t(int, int);
=09t(llong, long long);
=09t(baa, struct baa);
=09o(baa.a, a);
=09o(baa.b, b);
=09return (0);
}

bye,
//mirabilos
--=20
[16:04:33] bkix: "veni vidi violini"
[16:04:45] bkix: "ich kam, sah und vergeigte"...

[John Paul Adrian Glaubitz]

Post by Finn Thain

Post by Finn Thain
https://gcc.gnu.org/wiki/RustFrontEnd

That’s assuming it can build the same stuff the same way so it can be
used in packaging.

Not an assumption. I simply pointed out an opportunity for collaboration,
because I see the primary problem facing the m68k port is a lack of
resources.

There is hardly anyone to collaborate with. Plus, the problem is that 99%
the upstream projects will not carry any patches that unbreak their software
on m68k.

Post by Finn Thain

Post by Finn Thain
I expect alignment assumptions like that will end up putting more
platforms in the same predicament in future.

No, all the other platforms use natural alignment.

Post by Finn Thain
"Natural" alignment is meaningless in the context of portable data
structures, as they exist without reference to any particular integer

Yeah, but in practice, all we have is ILP32 and LP64;

... for now.

Sorry, but this a moot argument. Arguing with what could be in 50 years isn't
helpful here if it just intended to quench the discussion.

Post by Finn Thain

the Windows® world has LLP64 in addition. And natural alignment just
means that all the data types’ alignment is their size. (Which kind of
makes sense, so you can read them without getting an unalignment trap on
SPARC or so.)

That would mean __alignof__(foo.b) == sizeof(foo.b) but that's not the
struct baa {
int a;
long long b;
} foo;

Post by Finn Thain
Q. What is the size of this struct, assuming baa.b is naturally aligned?
struct baa {
int a;
long long b;
};

For ILP32, LP64 and LLP64, it’s 4 (a) + 4 (padding) + 8 (b) = 16 chars.

So natural alignment is portable if you first assume a data model. But the
struct definition itself is not portable, since it doesn't specify a data
model.

More importantly, and relevant for Qt, struct baa is also 8-byte
aligned...

If the struct itself is not naturally aligned, it too will eventually
break someone's assumption of natural alignment.

All this discussion doesn't help solve the real world problems with the m68k port.

Adrian

[John Paul Adrian Glaubitz]

Post by Finn Thain
I think that's overstating the case. Alternatives to rust are available
and will be for the foreseeable future. Most notably,

That’s not the point. Google, for example, are aggressively funding
people to throw away perfectly working code and rewrite it in rust,
or to at least add rust to projects. librsvg has been such a case for
some time already, python-cryptography is, but now we’re losing even
freetype (!!!) and, possibly, even the Linux kernel.

Post by Finn Thain
https://gcc.gnu.org/wiki/RustFrontEnd

That’s assuming it can build the same stuff the same way so it can
be used in packaging.

Again, it isn't just about Rust. Virtually every relevant project requires
32-bit alignment these days, including CPython. I assume that CPython is
nothing that anyone here would call exotic or killing open-source, no?

https://buildd.debian.org/status/fetch.php?pkg=python3.13&arch=m68k&ver=3.13.0-1&stamp=1728344123&raw=0

Post by Finn Thain
I expect alignment assumptions like that will end up putting more
platforms in the same predicament in future.

No, all the other platforms use natural alignment.

Yup, m68k is the only port in Debian with these issues.

Post by Finn Thain
"Natural" alignment is meaningless in the context of portable data
structures, as they exist without reference to any particular integer

Yeah, but in practice, all we have is ILP32 and LP64; the Windows®
world has LLP64 in addition. And natural alignment just means that
all the data types’ alignment is their size. (Which kind of makes
sense, so you can read them without getting an unalignment trap on
SPARC or so.)

Post by Finn Thain
Q. What is the size of this struct, assuming baa.b is naturally aligned?
struct baa {
        int a;
        long long b;
};

For ILP32, LP64 and LLP64, it’s 4 (a) + 4 (padding) + 8 (b) = 16 chars.
More importantly, and relevant for Qt, struct baa is also 8-byte
aligned, and malloc(3) results are usually 8‑ or even 16-byte aligned.

Adrian

[John Paul Adrian Glaubitz]

Post by Finn Thain
I think that's overstating the case. Alternatives to rust are available
and will be for the foreseeable future. Most notably,
https://safecpp.org/draft.html
Loading Image...
I agree with your sentiment though, in that rust generally gets a lot of
funding and hype. Even if the Rust Foundation doesn't care about
supporting the backend for m68k, there is still a way for non-commercially
viable platforms to collaborate. In particular,
https://gcc.gnu.org/wiki/RustFrontEnd

This is getting off-topic.

Post by Finn Thain

Post by Thorsten Glaser

Post by Finn Thain
Absent the right conditions, perhaps it is best focus limited porter and
developer effort on patching only those packages that are really required.

I tried my hand at Qt5. About 20 man-hours in I essentially gave up,
and that was without even getting to something I could put to a
compile and runtime test.

I take your point about the amount of effort required (and the lack of
resources). The answer may be to share the work better by enabling more
collaboration.

The "collaboration" currently means me doing 100% of the Debian/m68k work.

Post by Finn Thain
It appears that NetBSD/m68k has naturally aligned ints. Perhaps you could
look at adding kernel support for their ABI, and get access to Qt and LLVM
that way, without impacting the existing ABI and its ecosystem.

What ecosystem? Do you honestly care that any hobbyist cares about having
to reinstall their retro computers?

Post by Finn Thain
BTW, it has long annoyed me that two different 68k Mac bootloaders exist,
one each for Linux and NetBSD, which are duplicated effort, and have
different sets of bugs. To my mind, this is another good opportunity to
collaborate and avoid wasted developer effort (perhaps by dual licensing).

Again off-topic.

Post by Finn Thain

Post by Thorsten Glaser
“Natural” alignment of data types has essentially become a requirement
these days, and m68k is the only true outlyer (i386 could in theory, but
the Unix psABI designers were sensible enough to not do it).

I expect alignment assumptions like that will end up putting more
platforms in the same predicament in future. "Natural" alignment is
meaningless in the context of portable data structures, as they exist
without reference to any particular integer unit. It is because your
struct patches improve portability that I'd expect those patches to remain
acceptable upstream.
Q. What is the size of this struct, assuming baa.b is naturally aligned?
struct baa {
int a;
long long b;
};

We're dealing with today's software and not something that exists in 50 years.

Adrian

[Finn Thain]

Post by John Paul Adrian Glaubitz
What ecosystem? Do you honestly care that any hobbyist cares about
having to reinstall their retro computers?

The issue is not just old binaries. You made the same mistake in your
message to Arnd when you said "we're not allowed to fix that [ABI] because
someone might run an old binary". For some reason you're choosing to
ignore numerous objections that have been covered on the mailing lists to
date.

[John Paul Adrian Glaubitz]

Post by Finn Thain

Post by John Paul Adrian Glaubitz
What ecosystem? Do you honestly care that any hobbyist cares about
having to reinstall their retro computers?

The issue is not just old binaries. You made the same mistake in your
message to Arnd when you said "we're not allowed to fix that [ABI] because
someone might run an old binary". For some reason you're choosing to
ignore numerous objections that have been covered on the mailing lists to
date.

I have only seen real objections from your side. Everyone else agrees that
future development of the platform is not feasible without making the switch.

Adrian

[Finn Thain]

Post by John Paul Adrian Glaubitz

Post by Finn Thain

Post by John Paul Adrian Glaubitz
What ecosystem? Do you honestly care that any hobbyist cares about
having to reinstall their retro computers?

The issue is not just old binaries. You made the same mistake in your
message to Arnd when you said "we're not allowed to fix that [ABI] because
someone might run an old binary". For some reason you're choosing to
ignore numerous objections that have been covered on the mailing lists to
date.

I have only seen real objections from your side. Everyone else agrees
that future development of the platform is not feasible without making
the switch.

I'm interested in what people have to say. I'm not interested in who says
it. Hence, your concept of "everyone else" is irrelevant to me.

[John Paul Adrian Glaubitz]

Post by Thorsten Glaser

Post by Finn Thain
That seems to imply that someone requires that those packages are ported.

Yes, we do. Rust especially is killing the entire FOSS ecosystem.

Could we leave out politics out of this discussion, please?

Post by Thorsten Glaser
These all are conditio sine qua nōn when it comes to continuing
Linux/m68k, as a whole.

Exactly.

Post by Thorsten Glaser

Post by Finn Thain
Absent the right conditions, perhaps it is best focus limited porter and
developer effort on patching only those packages that are really required.

I tried my hand at Qt5. About 20 man-hours in I essentially gave up,
and that was without even getting to something I could put to a
compile and runtime test.

Yep, that's exactly my experience as well while building with 32-bit alignment
just made it work.

Post by Thorsten Glaser
“Natural” alignment of data types has essentially become a requirement
these days, and m68k is the only true outlyer (i386 could in theory, but
the Unix psABI designers were sensible enough to not do it).

Agreed.

Adrian

[John Paul Adrian Glaubitz]

Post by Finn Thain

Post by John Paul Adrian Glaubitz
- mold
- LLVM
- gccgo
- Qt5 (several packages affected)
- Qt6 (several packages affected)
- OpenJDK (all versions)
- Python >= 3.13
- Rust

That seems to imply that someone requires that those packages are ported.
But without a bug report from such a user, to say the package is broken or
missing, one must question the real requirement.

People have tried this in the past and it was an endless effort. It's not that
it hasn't been tried. And there is zero chance that any of these projects accept
such patches to support unusual alignment.

It's not that I'm not speaking from experience having maintained the m68k port
in Debian the past 10 years. The Gentoo folks will tell you the same.

Post by Finn Thain

Post by John Paul Adrian Glaubitz
Those are the most important projects from the tip of my head, but they
are already the biggest blockers. There is no chance that the upstream
maintainers will adjust their packages for 16-bit alignment, so these
will be forever broken on m68k if we don't switch.

I'm curious to see such a refusal in context, presumably as a result of
patch review, in an upstream project bug tracker.
I'm not actually expecting to see good patches refused by core projects
like Python. (Note that MicroPython is available for commercially active
CPUs like the PIC16 family, which are 8-bit processors with 16-bit address
bus.)

Why does my word not count here? It's not that this problem is new.

You can also ask Andreas who maintained openSUSE on m68k for a while and
had to carry lots of local patches.

Post by Finn Thain
If upstream QT or Java developers decide that their software is "not for
us", they may well have a point. Those packages are not installed on my
m68k systems, FWIW.

This is isn't just about runtime dependencies but also build dependencies
which is why I linked the statistics page in Debian. A lot of packages in
Debian/m68k can currently not be built because they have a transitive
dependency on Rust, OpenJDK, Qt, GNOME and so on.

Post by Finn Thain
OTOH, as I've said before, if upstream developers (like Arnd) are looking
ahead to 128-bit platforms then they will be paying attention to alignment
rules. They should be inclined to favour explicit struct definitions over
implicit alignment, don't you think?

Debian just transitioned all of their 32-bit architectures to time64_t except
for i386. Do you know why they did that even though 128-bit CPUs are practically
around the corner?

Post by Finn Thain

Post by John Paul Adrian Glaubitz
I understand that this might be a painful transition, but I don't see
any other way to keep the m68k port alive in the foreseeable future
unless we fix this problem which keeps blocking the port.
You can see how the Debian m68k port has been falling behind because of
https://buildd.debian.org/stats/graph-ports-big.png

I could imagine a viable transition to a new ABI driven by widespread user
demand or involvement. But not by distro stats or maintainer preference.

Well, I'm doing the work, so I get to make the decisions here, no?

Post by Finn Thain
Absent the right conditions, perhaps it is best focus limited porter and
developer effort on patching only those packages that are really required.

Thanks, but I tried that and it doesn't work. I don't want to continue spending
hours on trying to figure out how to fix alignment problems and then maybe send
an email here and there to just never get an answer.

You're somehow implying that I'm requesting this change because I'm just lazy.

Adrian

[Finn Thain]

Post by John Paul Adrian Glaubitz

Post by Finn Thain
That seems to imply that someone requires that those packages are
ported. But without a bug report from such a user, to say the package
is broken or missing, one must question the real requirement.

People have tried this in the past and it was an endless effort. It's
not that it hasn't been tried. And there is zero chance that any of
these projects accept such patches to support unusual alignment.

Then don't leave it to chance.

Post by John Paul Adrian Glaubitz
It's not that I'm not speaking from experience having maintained the
m68k port in Debian the past 10 years. The Gentoo folks will tell you
the same.

Post by Finn Thain

Post by John Paul Adrian Glaubitz
Those are the most important projects from the tip of my head, but
they are already the biggest blockers. There is no chance that the
upstream maintainers will adjust their packages for 16-bit
alignment, so these will be forever broken on m68k if we don't
switch.

I'm curious to see such a refusal in context, presumably as a result
of patch review, in an upstream project bug tracker.
I'm not actually expecting to see good patches refused by core
projects like Python. (Note that MicroPython is available for
commercially active CPUs like the PIC16 family, which are 8-bit
processors with 16-bit address bus.)

Why does my word not count here? It's not that this problem is new.

Your opinion does not count here because the question was about upstream
patch refusals. I'm genuinely interested to see the patch reviews. After
all, many alignment patches have already been merged.

Without being able to see the actual response from upstream developers, I
can only assume that they have either misunderstood the issue or they have
simply decided their users would not be served by an m68k port. Do you
agree that upstream developers generally know their users requirements
better than distros do?

Post by John Paul Adrian Glaubitz
You can also ask Andreas who maintained openSUSE on m68k for a while and
had to carry lots of local patches.

Post by Finn Thain
If upstream QT or Java developers decide that their software is "not
for us", they may well have a point. Those packages are not installed
on my m68k systems, FWIW.

This is isn't just about runtime dependencies but also build
dependencies which is why I linked the statistics page in Debian. A lot
of packages in Debian/m68k can currently not be built because they have
a transitive dependency on Rust, OpenJDK, Qt, GNOME and so on.

That's one reason why source distros are a better fit for small systems
than binary distros are. You can't fix this basic problem with an ABI
change.

Post by John Paul Adrian Glaubitz

Post by Finn Thain
OTOH, as I've said before, if upstream developers (like Arnd) are
looking ahead to 128-bit platforms then they will be paying attention
to alignment rules. They should be inclined to favour explicit struct
definitions over implicit alignment, don't you think?

Debian just transitioned all of their 32-bit architectures to time64_t
except for i386. Do you know why they did that even though 128-bit CPUs
are practically around the corner?

Perhaps they have explained their actions? Do you have an opinion?

Post by John Paul Adrian Glaubitz

Post by Finn Thain

Post by John Paul Adrian Glaubitz
I understand that this might be a painful transition, but I don't
see any other way to keep the m68k port alive in the foreseeable
future unless we fix this problem which keeps blocking the port.
You can see how the Debian m68k port has been falling behind because
https://buildd.debian.org/stats/graph-ports-big.png

I could imagine a viable transition to a new ABI driven by widespread
user demand or involvement. But not by distro stats or maintainer
preference.

Well, I'm doing the work, so I get to make the decisions here, no?

Sure. Please refer to my previous email about the m68k ABI du jour and
fragmentation.

Post by John Paul Adrian Glaubitz

Post by Finn Thain
Absent the right conditions, perhaps it is best focus limited porter
and developer effort on patching only those packages that are really
required.

Thanks, but I tried that and it doesn't work. I don't want to continue
spending hours on trying to figure out how to fix alignment problems and
then maybe send an email here and there to just never get an answer.
You're somehow implying that I'm requesting this change because I'm just lazy.

You're somehow twisting my words into a slur. You know that I value your
alignment patches because I've said so before. Thanks again for your
efforts.

[John Paul Adrian Glaubitz]

Post by Finn Thain

Post by John Paul Adrian Glaubitz

Post by Finn Thain
That seems to imply that someone requires that those packages are
ported. But without a bug report from such a user, to say the package
is broken or missing, one must question the real requirement.

People have tried this in the past and it was an endless effort. It's
not that it hasn't been tried. And there is zero chance that any of
these projects accept such patches to support unusual alignment.

Then don't leave it to chance.

What is supposed to mean? Are you implying that I never tried to address this?

Did you have a try at fixing any of these?

Post by Finn Thain

Post by John Paul Adrian Glaubitz
Why does my word not count here? It's not that this problem is new.

Your opinion does not count here because the question was about upstream
patch refusals. I'm genuinely interested to see the patch reviews. After
all, many alignment patches have already been merged.

Of course my opinion counts here because I am doing the majority of the work
on Debian m68k these days.

Post by Finn Thain
Without being able to see the actual response from upstream developers, I
can only assume that they have either misunderstood the issue or they have
simply decided their users would not be served by an m68k port. Do you
agree that upstream developers generally know their users requirements
better than distros do?

Again, this has been tried in the past and I'm tired of discussing this.

This kind of discussion doesn't really help resolving this problem.

Post by Finn Thain

Post by John Paul Adrian Glaubitz
You can also ask Andreas who maintained openSUSE on m68k for a while and
had to carry lots of local patches.

Post by Finn Thain
If upstream QT or Java developers decide that their software is "not
for us", they may well have a point. Those packages are not installed
on my m68k systems, FWIW.

This is isn't just about runtime dependencies but also build
dependencies which is why I linked the statistics page in Debian. A lot
of packages in Debian/m68k can currently not be built because they have
a transitive dependency on Rust, OpenJDK, Qt, GNOME and so on.

That's one reason why source distros are a better fit for small systems
than binary distros are. You can't fix this basic problem with an ABI
change.

Gentoo has the same problem with Linux m68k and they want to perform the switch
as well. So it's not just my personal opinion here.

Post by Finn Thain

Post by John Paul Adrian Glaubitz

Post by Finn Thain
OTOH, as I've said before, if upstream developers (like Arnd) are
looking ahead to 128-bit platforms then they will be paying attention
to alignment rules. They should be inclined to favour explicit struct
definitions over implicit alignment, don't you think?

Debian just transitioned all of their 32-bit architectures to time64_t
except for i386. Do you know why they did that even though 128-bit CPUs
are practically around the corner?

Perhaps they have explained their actions? Do you have an opinion?

My opinion is that people expect 32-bit targets to not dissolve in thin air
in 2038. The fact that i386 was not touch is simply because of the huge
library of pre-compiled software for the platform which doesn't exist in
that form on m68k. So that's not an argument to switch the natural alignment.

Post by Finn Thain

Post by John Paul Adrian Glaubitz

Post by Finn Thain

Post by John Paul Adrian Glaubitz
I understand that this might be a painful transition, but I don't
see any other way to keep the m68k port alive in the foreseeable
future unless we fix this problem which keeps blocking the port.
You can see how the Debian m68k port has been falling behind because
https://buildd.debian.org/stats/graph-ports-big.png

I could imagine a viable transition to a new ABI driven by widespread
user demand or involvement. But not by distro stats or maintainer
preference.

Well, I'm doing the work, so I get to make the decisions here, no?

Sure. Please refer to my previous email about the m68k ABI du jour and
fragmentation.

What fragmentation? The vast majority of people interested in this architecture
want to progress and not keep the status quo forever. And the switch is simply
inevitable which is why Chewi has pitched a proposal on this list as well.

Post by Finn Thain

Post by John Paul Adrian Glaubitz

Post by Finn Thain
Absent the right conditions, perhaps it is best focus limited porter
and developer effort on patching only those packages that are really
required.

Thanks, but I tried that and it doesn't work. I don't want to continue
spending hours on trying to figure out how to fix alignment problems and
then maybe send an email here and there to just never get an answer.
You're somehow implying that I'm requesting this change because I'm just lazy.

You're somehow twisting my words into a slur. You know that I value your
alignment patches because I've said so before. Thanks again for your
efforts.

Look, the problem is that this is a) an endless effort and b) in some cases
simply not feasible. Codebases like LLVM are completely built around a natural
alignment of at least four bytes and it's simply impossible to work around
that.

There are so many other things I would like to work on and I simply consider
it a waste of time and resources to work on the same problem over and over
again just because we cannot agree on finally fixing the underlying issue.

As of now, Debian/m68k will miss the transition to Python 3.13 because the
new version requires 4-byte alignment and absolutely no one is willing to
help me fix this issue.

All I'm getting is "wise" advise on the quality of "Have you tried turning it
off and on again?".

Endlessly frustrated,

Adrian

[Finn Thain]

Post by John Paul Adrian Glaubitz

Post by Finn Thain
Then don't leave it to chance.

What is supposed to mean? Are you implying that I never tried to address this?

Obviously, it means I'm not interested in your estimation of the chances
of rejection. But you're still trying to twist my words into a slur. How
tiresome.

Again, I'd like to see an actual example of upstream developers rejecting
patches that improve portability of data structures to m68k (and to 16-bit
systems).

Post by John Paul Adrian Glaubitz
Did you have a try at fixing any of these?

Would you like me to stop fixing bugs that users actually report, in order
to fix bugs that only distros complain about?

Post by John Paul Adrian Glaubitz

Post by Finn Thain

A lot of packages in Debian/m68k can currently not be built because
they have a transitive dependency on Rust, OpenJDK, Qt, GNOME and so
on.

That's one reason why source distros are a better fit for small
systems than binary distros are. You can't fix this basic problem with
an ABI change.

Gentoo has the same problem with Linux m68k and they want to perform the
switch as well. So it's not just my personal opinion here.

Again, the real problem faced by Debian/m68k and Gentoo/m68k is a shortage
of manpower. This is not a new problem.

An ABI change will not fix this problem though I do conceed that a
different ABI could improve the distro's package archive statistics, for
all that's worth.

Post by John Paul Adrian Glaubitz

Post by Finn Thain

Well, I'm doing the work, so I get to make the decisions here, no?

Sure. Please refer to my previous email about the m68k ABI du jour and
fragmentation.

What fragmentation? The vast majority of people interested in this
architecture want to progress and not keep the status quo forever. And
the switch is simply inevitable which is why Chewi has pitched a
proposal on this list as well.

No, you're not really interested in progress. There's nothing particularly
novel about running bloated packages in fast emulators.

And yet, I do agree that actual progress would require a new ABI, and
you've even heard me say so before though you appear to have forgotten.
https://lists.debian.org/debian-68k/2023/08/msg00023.html

Post by John Paul Adrian Glaubitz

Post by Finn Thain

Post by Finn Thain
Absent the right conditions, perhaps it is best focus limited
porter and developer effort on patching only those packages that
are really required.

Thanks, but I tried that and it doesn't work. I don't want to
continue spending hours on trying to figure out how to fix alignment
problems and then maybe send an email here and there to just never
get an answer.
You're somehow implying that I'm requesting this change because I'm just lazy.

You're somehow twisting my words into a slur. You know that I value
your alignment patches because I've said so before. Thanks again for
your efforts.

Look, the problem is that this is a) an endless effort and b) in some
cases simply not feasible. Codebases like LLVM are completely built
around a natural alignment of at least four bytes and it's simply
impossible to work around that.

If LLVM developers say that their software is inappropriate for an ABI
that does not have 4-byte minimal alignment (citation needed) then I'd
accept their judgement on that.

And when I want to run LLVM and its reverse deps on my m68k systems, I'll
run them under NetBSD/mac68k.

Post by John Paul Adrian Glaubitz
There are so many other things I would like to work on and I simply
consider it a waste of time and resources to work on the same problem
over and over again just because we cannot agree on finally fixing the
underlying issue.

Then don't work on it.

My Gentoo/x86 laptop installation is now twenty one years old, is
up-to-date, and has never had LLVM installed on it. Nor do I miss it.

nippy portage # wc -l /var/log/emerge.log
409801 /var/log/emerge.log
nippy portage # head /var/log/emerge.log
1063261888: Started emerge on: Sep 11, 2003 06:31:27
1063261888: *** emerge >=sys-apps/portage-2.0.25
1063261888: >>> emerge (1 of 1) sys-apps/portage-2.0.49-r4 to /
1063261888: === (1 of 1) Cleaning (/usr/portage/sys-apps/portage/portage-2.0.49-r4.ebuild)
1063261888: === (1 of 1) Compiling/Merging (/usr/portage/sys-apps/portage/portage-2.0.49-r4.ebuild)
1063261911: === (1 of 1) Post-Build Cleaning (/usr/portage/sys-apps/portage/portage-2.0.49-r4.ebuild)
1063261911: ::: completed emerge (1 of 1) sys-apps/portage-2.0.49-r4 to /
1063261911: *** Finished. Cleaning up...
1063261911: *** exiting successfully.
1063261911: *** terminating.

Post by John Paul Adrian Glaubitz
As of now, Debian/m68k will miss the transition to Python 3.13 because
the new version requires 4-byte alignment and absolutely no one is
willing to help me fix this issue.

I'm keen to see where the python requirements were changed. I wasn't able
to find that document on python.org.

If you don't want to port python 3.13 to m68k that's okay with me. And if
you're unwilling to port any packages to any quirky architectures, that's
okay with me too.

But if you still claim that upstream developers require certain alignment
rules, then you still have to provide evidence for that. Despite all of my
requests for that evidence, none has been offered.

[Finn Thain]

Post by John Paul Adrian Glaubitz
the m68k port has reached the point where switching the default
alignment from 16-bit to 32-bit is inevitable as the number of packages
affected by alignment issues have become too large. It even includes
Python 3.13 these days.

Are there any bug reports you could link to, in support of the "too large"
claim?

[John Paul Adrian Glaubitz]

Hi Arnd,

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

[Arnd Bergmann]

Post by John Paul Adrian Glaubitz

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.

Post by John Paul Adrian Glaubitz

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.

Post by John Paul Adrian Glaubitz

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.

Post by John Paul Adrian Glaubitz
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

[Andreas Schwab]

Post by Arnd Bergmann
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.

That's why I didn't change the alignment when I implemented ELF. It
would have made it impossible to mix an a.out kernel with ELF user
space, and vice versa.

[John Paul Adrian Glaubitz]

Post by Andreas Schwab

Post by Arnd Bergmann
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.

That's why I didn't change the alignment when I implemented ELF. It
would have made it impossible to mix an a.out kernel with ELF user
space, and vice versa.

Thanks for explaining the background. However, it doesn't change the
fact that this is blocking a lot of software now, unfortunately.

Adrian

[Thorsten Glaser]

Post by John Paul Adrian Glaubitz
as m68k has supported 32-bit alignment through the "-malign-int"
switch for a long time.

That switch constitutes a fundamental ABI change, even if
the effect is limited.

Question is, do we need a kernel change for this at all?
Is there anything in the kernel/userland interface that
gets affected by this, or do these APIs use sufficient
explicit padding? Has anyone looked at this?

If we know that the answer is no, the plan could look
different from a yes answer, so=E2=80=A6

Additionally=E2=80=A6 has anyone done the simple =E2=80=9Cenable -malign-in=
t
in GCC, begin rebuilding stuff, first glibc, then others,
see what breaks=E2=80=9D? Is there sufficient effect that we cannot
incrementally change over?

(Another question: does -malign-int switch to natural
alignment for all types, i.e. 64 bit for llong and double,
etc. or are we going to have to change GCC first as well
to avoid more surprises?)

bye,
//mirabilos
--=20
Solange man keine schmutzigen Tricks macht, und ich meine *wirklich*
schmutzige Tricks, wie bei einer doppelt verketteten Liste beide
Pointer XORen und in nur einem Word speichern, funktioniert Boehm ganz
hervorragend.=09=09-- Andreas Bogk =C3=BCber boehm-gc in d.a.s.r

[Andreas Schwab]

Post by Thorsten Glaser
Question is, do we need a kernel change for this at all?
Is there anything in the kernel/userland interface that
gets affected by this, or do these APIs use sufficient
explicit padding? Has anyone looked at this?

Already basic things like struct stat64 will break.

[Thorsten Glaser]

Post by Andreas Schwab
Already basic things like struct stat64 will break.

OK. Then, flag day, I guess.

How do we model this in Debian. Rename libc to libc6.1 and
conflict with libc6 to force no co=C3=AFnstallability, rename the
architecture from m68k to=E2=80=A6 something else, or=E2=80=A6?

But then, this does give the kernel side a chance to clean
it up, even to model it like a completely new ILP32 port with
no historical things to account for. And no kernel then needs
to support both at the same time. (Or the new syscall ABI
could use something different than trap #0, if that is even
possible.)

How do we model this on the ELF side? (How do ARM and MIPS
distinguish between their different same-bitness ABIs there?)
Or do we just keep everything and old programs will just fail
on their first syscall? (Another point in favour of not using
the same trap.) Less toolchain changes. This also impacts how
distros can handle this. From what mgorny writes Gentoo also
doesn=E2=80=99t like rebootstrap-everything flag days with no simple
upgradability, but it looks like this can=E2=80=99t be avoided with
justifiable effort=E2=80=A6 unless the new ABI uses a different trap,
the kernel supports both at the same time, and ELF mechanisms
*and* paths (e.g. Multi-Arch) are used to distinguish them,
so they can co=C3=ABxist in the same system. (Although different
M-A path would (I think) mean different Debian architecture,
so it=E2=80=99d not be a clean upgrade either; crossgrades do work in
theory these days, but only if the package versions are
exactly identical, so this is very much not going to happen
for m68k.)

So I think we need a rebootstrap with requiring users to
reinstall (and then need no coexistence within the same
running system).

Can we cheat and just not change the dpkg arch, GNU triplet,
ELF headers etc. and just make sure that old syscalls won=E2=80=99t
continue to work? (Or, some could even continue to work.)
The danger of this is that if someone has an old .a lying
around and links to it, they can get misbehaviour *if* it
is affected by the ABI change.

Otherwise, I think we at least need something ELFy that
binutils will refuse to link with older ELFs and go from
there.

Looking at binutils=E2=80=A6 ARM has special code like:

/* Cannot mix APCS26 and APCS32 code. */
if ((in_flags & EF_ARM_APCS_26) !=3D (out_flags & EF_ARM_APCS_26))
return FALSE;

/* Cannot mix float APCS and non-float APCS code. */
if ((in_flags & EF_ARM_APCS_FLOAT) !=3D (out_flags & EF_ARM_APCS_FLOA=
T))
return FALSE;

But m68k doesn=E2=80=99t, so old binutils would link against new
objects if we just add something like EF_* there. Again,
the question is how much we can =E2=80=9Ccheat=E2=80=9D for a low-user-
count arch vs. how correct we want to do this. I=E2=80=99m not
sure allocating a new EM_* distinct from EM_68K would be
globally welcomed. (On that note, there=E2=80=99s EM_COLDFIRE, but
Linux/coldfire never took off, did it?) No EI_OSABI use,
either. So, besides new EM_*, I can=E2=80=99t think of a way that
old binutils won=E2=80=99t mix objects (and old kernels won=E2=80=99t try
to execute new binaries), unless making things fail at the
first syscall is an option, but getting one will mean more
delays and more to change.

So many ways=E2=80=A6

bye,
//mirabilos
--=20
=E2=80=9ECool, /usr/share/doc/mksh/examples/uhr.gz ist ja ein Grund,
mksh auf jedem System zu installieren.=E2=80=9C
=09-- XTaran auf der OpenRheinRuhr, ganz begeistert
(EN: =E2=80=9C[=E2=80=A6]uhr.gz is a reason to install mksh on every system=
=2E=E2=80=9D)

[Greg Ungerer]

Post by Thorsten Glaser

Post by Andreas Schwab
Already basic things like struct stat64 will break.

OK. Then, flag day, I guess.
How do we model this in Debian. Rename libc to libc6.1 and
conflict with libc6 to force no coïnstallability, rename the
architecture from m68k to… something else, or…?
But then, this does give the kernel side a chance to clean
it up, even to model it like a completely new ILP32 port with
no historical things to account for. And no kernel then needs
to support both at the same time. (Or the new syscall ABI
could use something different than trap #0, if that is even
possible.)
How do we model this on the ELF side? (How do ARM and MIPS
distinguish between their different same-bitness ABIs there?)
Or do we just keep everything and old programs will just fail
on their first syscall? (Another point in favour of not using
the same trap.) Less toolchain changes. This also impacts how
distros can handle this. From what mgorny writes Gentoo also
doesn’t like rebootstrap-everything flag days with no simple
upgradability, but it looks like this can’t be avoided with
justifiable effort… unless the new ABI uses a different trap,
the kernel supports both at the same time, and ELF mechanisms
*and* paths (e.g. Multi-Arch) are used to distinguish them,
so they can coëxist in the same system. (Although different
M-A path would (I think) mean different Debian architecture,
so it’d not be a clean upgrade either; crossgrades do work in
theory these days, but only if the package versions are
exactly identical, so this is very much not going to happen
for m68k.)
So I think we need a rebootstrap with requiring users to
reinstall (and then need no coexistence within the same
running system).
Can we cheat and just not change the dpkg arch, GNU triplet,
ELF headers etc. and just make sure that old syscalls won’t
continue to work? (Or, some could even continue to work.)
The danger of this is that if someone has an old .a lying
around and links to it, they can get misbehaviour *if* it
is affected by the ABI change.
Otherwise, I think we at least need something ELFy that
binutils will refuse to link with older ELFs and go from
there.
/* Cannot mix APCS26 and APCS32 code. */
if ((in_flags & EF_ARM_APCS_26) != (out_flags & EF_ARM_APCS_26))
return FALSE;
/* Cannot mix float APCS and non-float APCS code. */
if ((in_flags & EF_ARM_APCS_FLOAT) != (out_flags & EF_ARM_APCS_FLOAT))
return FALSE;
But m68k doesn’t, so old binutils would link against new
objects if we just add something like EF_* there. Again,
the question is how much we can “cheat” for a low-user-
count arch vs. how correct we want to do this. I’m not
sure allocating a new EM_* distinct from EM_68K would be
globally welcomed. (On that note, there’s EM_COLDFIRE, but
Linux/coldfire never took off, did it?) No EI_OSABI use,

There is plenty of Linux on ColdFire, but all the m68k'isms apply the same.

Post by Thorsten Glaser
either. So, besides new EM_*, I can’t think of a way that
old binutils won’t mix objects (and old kernels won’t try
to execute new binaries), unless making things fail at the
first syscall is an option, but getting one will mean more
delays and more to change.
So many ways…
bye,
//mirabilos

[Thorsten Glaser]

I think it makes sense to go through these anyway and annotate
them to document and enforce the alignment we actually want

That would be good in general, yes. I=E2=80=99d personally argue for
using explicit padding members (please do NOT use __unused,
rather __pad1 __pad2 etc. or __unused1, etc. as __unused is
used (hah) by BSD code for the GCC attribute a lot) and in
cases where n=C5=8Dn-natural alignment is needed, GCC __packed__
plus explicit padding. That is easier to read than __aligned__.

TIL that GCC has a __warn_if_not_aligned__ attribute now,
which could be useful, but mostly for the code that makes
these assumptions, so not us here.

padding. If all of them get fixed alignment, this would allow
switching -malign-int on independently for userspace and
kernel without changing the ABI. Any duplicated copies of
the struct definitions in userspace of course would need
the same changes.

That is=E2=80=A6 an interesting side effect and probably a good idea
to decouple this=E2=80=A6 unless there are any *other* kernel-side
changes we absolutely need for this that we don=E2=80=99t want to put
atop via evolution, not revolution (i.e. whether there is any=E2=80=90
thing in the kernel/userspace boundary that direly needs to
change, for this or anyway, and is a breaking change=E2=80=A6 though
maybe even then).


On Sun, 27 Oct 2024, Greg Ungerer wrote:
=20

There is plenty of Linux on ColdFire, but all the m68k'isms apply the sam=

e.

Ah, okay. All of it nommu though?

Is there anything special we need to do or must not to that
relates to ColdFire? Anyone to put in the Cc list for that?

bye,
//mirabilos
--=20

Why don't you use JavaScript? I also don't like enabling JavaScript in

Because I use lynx as browser.

+1
=09-- Octavio Alvarez, me and =E2=A1=8D=E2=A0=81=E2=A0=97=E2=A0=8A=E2=A0=95=
(Mario Lang) on debian-devel

[Greg Ungerer]

I think it makes sense to go through these anyway and annotate
them to document and enforce the alignment we actually want

That would be good in general, yes. I’d personally argue for
using explicit padding members (please do NOT use __unused,
rather __pad1 __pad2 etc. or __unused1, etc. as __unused is
used (hah) by BSD code for the GCC attribute a lot) and in
cases where nōn-natural alignment is needed, GCC __packed__
plus explicit padding. That is easier to read than __aligned__.
TIL that GCC has a __warn_if_not_aligned__ attribute now,
which could be useful, but mostly for the code that makes
these assumptions, so not us here.

padding. If all of them get fixed alignment, this would allow
switching -malign-int on independently for userspace and
kernel without changing the ABI. Any duplicated copies of
the struct definitions in userspace of course would need
the same changes.

That is… an interesting side effect and probably a good idea
to decouple this… unless there are any *other* kernel-side
changes we absolutely need for this that we don’t want to put
atop via evolution, not revolution (i.e. whether there is any‐
thing in the kernel/userspace boundary that direly needs to
change, for this or anyway, and is a breaking change… though
maybe even then).

There is plenty of Linux on ColdFire, but all the m68k'isms apply the same.

Ah, okay. All of it nommu though?

No, there is a few ColdFire family members with MMU, specifically the version 4
core parts (547x, 548x, 5441x and 5445x). All supported by Linux, and popular
with some because they are significantly faster then the 68060. I regularly
(as in every mainline rc and kernel release) test on the 5475, and recently I
was sent a 54418 board and test on that now too.

To be fair though I build complete embedded systems and don't generally rely
on distros for a user space. So a flag day API change would not bother me at all.
That may well not be true for all ColdFire users though.

Is there anything special we need to do or must not to that
relates to ColdFire? Anyone to put in the Cc list for that?

Nothing special or different that I can think of. The struct alignment used
is the same as for standard m68k, so the problem is the same. The only user
space visible differences I can think of is the slight difference in layout
for the ptrace pt_regs struct. And those elements are probably problematic with
the mix of bit fields short/long at the end.

Regards
Greg

[John Paul Adrian Glaubitz]

Post by Andreas Schwab

Post by Thorsten Glaser
Question is, do we need a kernel change for this at all?
Is there anything in the kernel/userland interface that
gets affected by this, or do these APIs use sufficient
explicit padding? Has anyone looked at this?

Already basic things like struct stat64 will break.
https://marc.info/?l=glibc-help&m=169303990426196&w=2

Adrian

[John Paul Adrian Glaubitz]

Hello Arnd,

Post by Andreas Schwab

Post by Thorsten Glaser
Question is, do we need a kernel change for this at all?
Is there anything in the kernel/userland interface that
gets affected by this, or do these APIs use sufficient
explicit padding? Has anyone looked at this?

Already basic things like struct stat64 will break.

I tried writing a small script that compiles each exported
kernel header in order to get the debugging data for struct
definitions. This is the list of the 236 structures that
pahole reports being different with -malign-int. I probably
missed a small number in header files that failed to build
standalone, but this covers most.
I think it makes sense to go through these anyway and annotate
them to document and enforce the alignment we actually want
regardless of -malign-int, either by adding architecture
specific __packed/__aligned attributes, or by adding explicit
padding. If all of them get fixed alignment, this would allow
switching -malign-int on independently for userspace and
kernel without changing the ABI. Any duplicated copies of
the struct definitions in userspace of course would need
the same changes.

Thanks a lot! This is a very constructive contribution to the discussion.

I will create a page on the Debian (or Gentoo) Wiki to collect such information.

Adrian

---
struct _IOCTL_Command_struct {
struct _MGSL_PARAMS {
struct __fat_dirent {
struct __old_kernel_stat {
struct acrn_cstate_data {
struct acrn_pcidev {
struct atm_backend_ppp {
struct atm_qos {
struct atm_trafprm {
struct atmlec_config_msg {
struct atmlec_ioc {
struct atmlec_msg {
struct atmsvc_msg {
struct atmtcp_control {
struct ax25_ctl_struct {
struct ax25_route_opt_struct {
struct blk_user_trace_setup {
struct bpf_perf_event_data {
struct bpq_req {
struct br_mdb_entry {
struct br_mrp_in_role {
struct br_mrp_in_state {
struct br_mrp_instance {
struct br_mrp_start_in_test {
struct br_port_msg {
struct btrfs_ioctl_dev_replace_args {
struct btrfs_ioctl_dev_replace_start_par
struct cdrom_blk {
struct cdrom_generic_command {
struct cdrom_multisession {
struct cdrom_read_audio {
struct cdrom_subchnl {
struct cdrom_tocentry {
struct cycx_firmware {
struct cycx_fw_info {
struct dlm_lksb {
struct dlm_lock_result {
struct drm_etnaviv_pm_signal {
struct dvb_diseqc_slave_reply {
struct dvd_bca {
struct dvd_lu_send_title_key {
struct dvd_manufact {
struct dvd_physical {
struct ebt_arp_info {
struct ebt_arpreply_info {
struct ebt_mark_m_info {
struct ebt_nat_info {
struct ebt_stp_config_info {
struct ebt_stp_info {
struct edd {
struct efs_super {
struct eg_ctrl_info {
struct ethtool_ah_espip4_spec {
struct ethtool_ah_espip6_spec {
struct ethtool_rx_ntuple_flow_spec {
struct ethtool_tcpip4_spec {
struct ethtool_tcpip6_spec {
struct ethtool_usrip6_spec {
struct ethtool_wolinfo {
struct fat_boot_sector {
struct fb_cursor {
struct fb_fix_screeninfo {
struct fb_image {
struct floppy_drive_params {
struct floppy_fdc_state {
struct fs_quota_stat {
struct full_sockaddr_ax25 {
struct full_sockaddr_rose {
struct hdr_output_metadata {
struct hdsp_config_info {
struct hdsp_version {
struct hdspm_peak_rms {
struct hdspm_status {
struct hdspm_version {
struct he_ioctl_reg {
struct hiddev_devinfo {
struct hv_kvp_msg {
struct i2c_msg {
struct i2c_smbus_ioctl_data {
struct i2o_sw_xfer {
struct idmap_msg {
struct ieee_pfc {
struct ifla_vf_vlan_info {
struct in_ctrl_info {
struct inet_diag_hostcond {
struct ip6t_ah {
struct ip6t_frag {
struct ip6t_rt {
struct ip6t_srh1 {
struct ip_set_counter_match0 {
struct ip_vs_dest_entry {
struct ip_vs_dest_user {
struct ip_vs_get_dests {
struct ip_vs_service_entry {
struct ip_vs_service_user {
struct ipmi_addr {
struct ipmi_ipmb_direct_addr {
struct ipmi_ssif_msg {
struct ipt_ah {
struct ipt_clusterip_tgt_info {
struct j1939_filter {
struct k_message {
struct loop_info {
struct media_link_desc {
struct media_pad_desc {
struct mf6cctl {
struct mfcctl {
struct mif6ctl {
struct msgbuf {
struct msginfo {
struct msqid_ds {
struct mtd_info_user {
struct mtop {
struct nd_papr_pdsm_health {
struct nd_papr_pdsm_smart_inject {
struct nf_nat_range2 {
struct nfs_mount_data {
struct nr_route_struct {
struct opal_geometry {
struct ovs_action_push_mpls {
struct ovs_key_arp {
struct ovs_key_ct_tuple_ipv4 {
struct ovs_key_ct_tuple_ipv6 {
struct pci_endpoint_test_xfer_param {
struct pg_read_hdr {
struct pg_write_hdr {
struct plipconf {
struct pt_regs {
struct ptrace_syscall_info {
struct qedr_create_qp_uresp {
struct rds6_info_rdma_connection {
struct rds_info_rdma_connection {
struct rio_rdev_info {
struct rkisp1_cif_isp_afc_config {
struct rkisp1_cif_isp_dpf_config {
struct rkisp1_cif_isp_dpf_nll {
struct rkisp1_cif_isp_isp_meas_cfg {
struct rkisp1_cif_isp_isp_other_cfg {
struct rkisp1_cif_isp_sdg_config {
struct rkisp1_cif_isp_stat {
struct rkisp1_ext_params_afc_config {
struct rkisp1_ext_params_dpf_config {
struct rkisp1_ext_params_sdg_config {
struct rkisp1_params_cfg {
struct rkisp1_stat_buffer {
struct rose_facilities_struct {
struct rtc_wkalrm {
struct scc_calibrate {
struct scc_modem {
struct scom_access {
struct semid_ds {
struct serial_multiport_struct {
struct serial_struct {
struct sigcontext {
struct sioc_mif_req6 {
struct sioc_vif_req {
struct sisfb_info {
struct snd_dm_fm_note {
struct snd_emu10k1_fx8010_pcm_rec {
struct snd_sb_csp_info {
struct snp_guest_request_ioctl {
struct sock_fprog {
struct sockaddr_atmpvc {
struct sockaddr_atmsvc {
struct sockaddr_ax25 {
struct sockaddr_caif {
struct sockaddr_can {
struct sockaddr_nfc {
struct sockaddr_nfc_llcp {
struct sockaddr_qrtr {
struct sockaddr_rose {
struct stat64 {
struct taskstats {
struct tc_connmark {
struct tc_ife {
struct tc_pedit_sel {
struct unimapdesc {
struct usb_raw_ep_info {
struct usb_raw_eps_info {
struct usbdevfs_connectinfo {
struct usbdevfs_urb {
struct uvc_xu_control_query {
struct uvesafb_task {
struct vbg_ioctl_log {
struct vduse_iotlb_entry {
struct vduse_vq_info {
struct vfio_device_info_cap_zpci_group {
struct virtio_net_hash_config {
struct virtio_net_rss_config {
struct vlan_ioctl_args {
struct xfrm_encap_tmpl {
struct xfrm_selector {
struct xfrm_user_acquire {
struct xfrm_user_expire {
struct xfrm_user_kmaddress {
struct xfrm_user_offload {
struct xfrm_user_polexpire {
struct xfrm_user_report {
struct xfrm_userpolicy_id {
struct xfrm_userpolicy_info {
struct xfrm_usersa_info {
struct xfrm_userspi_info {
struct xsdfec_ldpc_params {
struct xsdfec_status {
struct xsdfec_turbo {
struct xt_bpf_info {
struct xt_connmark_mtinfo1 {
struct xt_connmark_tginfo1 {
struct xt_conntrack_mtinfo2 {
struct xt_conntrack_mtinfo3 {
struct xt_entry_match {
struct xt_entry_target {
struct xt_error_target {
struct xt_esp {
struct xt_helper_info {
struct xt_hmark_info {
struct xt_ipcomp {
struct xt_iprange_mtinfo {
struct xt_mac_info {
struct xt_mark_mtinfo1 {
struct xt_owner_match_info {
struct xt_realm_info {
struct xt_secmark_target_info {
struct xt_secmark_target_info_v1 {
struct xt_set_info_match_v0 {
struct xt_set_info_match_v3 {
struct xt_set_info_target_v0 {
struct xt_set_info_v0 {
struct xt_time_info {
struct xt_tproxy_target_info {
struct xt_tproxy_target_info_v1 {
struct xt_u32 {
struct xt_u32_location_element {
struct xt_u32_test {
union __sifields {
union ethtool_flow_union {

[Geert Uytterhoeven]

Hi Thorsten,

Additionally… has anyone done the simple “enable -malign-int
in GCC, begin rebuilding stuff, first glibc, then others,
see what breaks”? Is there sufficient effect that we cannot
incrementally change over?

I guess there is code out there that checks for e.g. __mc68000__
and will start doing the wrong thing...

Gr{oetje,eeting}s,

Geert

[John Paul Adrian Glaubitz]

Hi Geert,

Post by Geert Uytterhoeven

Additionally… has anyone done the simple “enable -malign-int
in GCC, begin rebuilding stuff, first glibc, then others,
see what breaks”? Is there sufficient effect that we cannot
incrementally change over?

I guess there is code out there that checks for e.g. __mc68000__
and will start doing the wrong thing...

Those are easier to fix though than trying to get LLVM work with
16-bit alignment. The former will just require removing that check.

Adrian

[John Paul Adrian Glaubitz]

Post by Thorsten Glaser

Post by John Paul Adrian Glaubitz
as m68k has supported 32-bit alignment through the "-malign-int"
switch for a long time.

That switch constitutes a fundamental ABI change, even if
the effect is limited.
Question is, do we need a kernel change for this at all?
Is there anything in the kernel/userland interface that
gets affected by this, or do these APIs use sufficient
explicit padding? Has anyone looked at this?

James Le Cuirot (chewi) has created a Gentoo/m68k chroot with 4-byte
alignment and most of the stuff just worked from what I remember.

Post by Thorsten Glaser
If we know that the answer is no, the plan could look
different from a yes answer, so…
Additionally… has anyone done the simple “enable -malign-int
in GCC, begin rebuilding stuff, first glibc, then others,
see what breaks”? Is there sufficient effect that we cannot
incrementally change over?

Yes, see above.

Post by Thorsten Glaser
(Another question: does -malign-int switch to natural
alignment for all types, i.e. 64 bit for llong and double,
etc. or are we going to have to change GCC first as well
to avoid more surprises?)

I assume so. Chewi, can you answer that question?

Adrian

[Geert Uytterhoeven]

Hi Thorsten,

Post by Thorsten Glaser

Post by John Paul Adrian Glaubitz
as m68k has supported 32-bit alignment through the "-malign-int"
switch for a long time.

That switch constitutes a fundamental ABI change, even if
the effect is limited.
Question is, do we need a kernel change for this at all?
Is there anything in the kernel/userland interface that
gets affected by this, or do these APIs use sufficient
explicit padding? Has anyone looked at this?

As pointed out by Arnd, there are.

Post by Thorsten Glaser
(Another question: does -malign-int switch to natural
alignment for all types, i.e. 64 bit for llong and double,
etc. or are we going to have to change GCC first as well
to avoid more surprises?)

It only changes alignment for short and larger from 2 to 4 bytes.
So long long and double are still aligned to 4 bytes instead of 8.
If we decide to change alignment, I'd rather change all types to
natural alignment, to avoid future nasty surprises.

What to do with long double, which is 12 bytes on m68k and i386?
I386 kept its alignment at 4, while amd64 changed both size and
alignment to 16.

Gr{oetje,eeting}s,

Geert

[Thorsten Glaser]

__alignof__(long long) =3D 8
but
sizeof(struct baa) =3D 12
__alignof__(struct baa) =3D 4
???
Isn't the alignment of a struct the largest alignment of any of its
members?

I=E2=80=99d say yes. Probably the i386 psABI is so old that it is very
weird and n=C5=8Dn-standard in some ways.

Post by Thorsten Glaser
(Another question: does -malign-int switch to natural
alignment for all types, i.e. 64 bit for llong and double,
etc. or are we going to have to change GCC first as well
to avoid more surprises?)

It only changes alignment for short and larger from 2 to 4 bytes.
So long long and double are still aligned to 4 bytes instead of 8.

Hmm hmm.

If we decide to change alignment, I'd rather change all types to
natural alignment, to avoid future nasty surprises.

That was my thought; the question is whether toolchain maintainers
(upstreams) will be amenable and helpful.

What to do with long double, which is 12 bytes on m68k and i386?
I386 kept its alignment at 4, while amd64 changed both size and
alignment to 16.

amd64=E2=80=99s long double is an SSE2 data type whereas i386=E2=80=99s is =
actually
an 80387 data type (same as m68k=E2=80=99s really), so they aren=E2=80=99t =
comparable.

I=E2=80=99d probably suggest aligning long double to 8 octets, like double.

It=E2=80=99s not a common data type (and probably one best avoided) anyway.

bye,
//mirabilos
--=20
(gnutls can also be used, but if you are compiling lynx for your own use,
there is no reason to consider using that package)
=09-- Thomas E. Dickey on the Lynx mailing list, about OpenSSL

[Arnd Bergmann]

Post by John Paul Adrian Glaubitz
Hello,
the m68k port has reached the point where switching the default alignment
from 16-bit to 32-bit is inevitable as the number of packages affected by
alignment issues have become too large. It even includes Python 3.13 these
days.
Since I don't think the situation is getting better by postponing action here
in the future, I suggest that we have a virtual meetup soonish to discuss a
strategy for switching the port over.
Maybe a page could be created either on the Debian or Gentoo Wiki to draft a design
for switching over. Geert also mentioned that we should use this transition to clean
up the kernel ABI by removing old syscalls and switch the kernel to asm-generic which
is why I have included Arnd Bergmann in the CC list.
Please join #gentoo-m68k on Libera if you want to discuss this issue.

Hi Adrian,

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.

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.

Examples of other ABI changes we had in the kernel are:

- ARM EABI was added before the architecture became
dominant, and ended up as a success. The structure
alignment differences between OABI and EABI were part of
it, but it was mostly pushed because of Thumb
instruction support, and with a huge investment of
development resources.

- PowerPC ELFv2 was a similar success, this one was driven
by a strong desire to allow little-endian distros, and
again was done with a very significant investment.

- MIPS/n32 and x86/x32 never took off despite the effort
put into them and the advantages for both the ABI and
performance compared to running traditional 32-bit
binaries on 64-bit kernels. As I understand, gentoo
still supports both, so clearly someone likes these, but
from a kernel perspective they still cause us headache
and were clearly a mistake. Attempts to do the same
on powerpc/arm64/riscv64 were rejected for these reasons.

- The big-endian ABIs for arm and arm64 were mostly a
complete failure, having been pushed for by network
SoC makers (Intel IXP mainly) before that industry moved
to little-endian. Adding these made a lot of sense at
the time when big-endian powerpc and mips owned that
market but has since turned into a liability. Nowadays
it's mainly used for regression-testing big-endian mode
on widely available hardware (arm64 VM guests).

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.

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.

Arnd

[Michael Schmitz]

Arnd,

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.

I second that - currently bisecting to find out what makes my extremely
RAM constrained m68k system fail to boot or run anything past 6.9-rc4
(sysvinit, not systemd).

Much as I appreciate Adrian's efforts to keep up with user space
development, I won't be in a position to help with an ABI change.

Cheers,

    Michael

[Finn Thain]

Post by Michael Schmitz

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.

I second that - currently bisecting to find out what makes my extremely
RAM constrained m68k system fail to boot or run anything past 6.9-rc4
(sysvinit, not systemd).

As cloud instances multiply, that small quantity of lost RAM gets
multiplied. So it appears that small systems aren't so strange, even after
they become unprofitable...

Post by Michael Schmitz
Much as I appreciate Adrian's efforts to keep up with user space
development, I won't be in a position to help with an ABI change.

Bloated m68k packages will continue to work -- given emulators that run
faster with every hardware upgrade. But how would such a distro add value?

I don't mind if Gentoo ships a separate profile for (downstream) ABI
experimentation, leaving the default m68k profile on the standard ABI.

And if Debian wants to switch ABI entirely, I won't object further, I've
said enough about the associated risks.

So I'll just reiterate that I'd rather see more collaboration instead -

1) among all small systems ports, to try to alleviate Debian's package
dependency problem

2) among all developers working on non-commercial architectures, to
improve the GCC Rust frontend

3) among all 680x0 developers interested in the NetBSD ABI

4) among all users of EOL'd hardware, so that value may continue to be
extracted from it (thanks to the efforts of Debian and Gentoo devs,
among others).

[John Paul Adrian Glaubitz]

Post by Finn Thain

Post by Michael Schmitz

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.

I second that - currently bisecting to find out what makes my extremely
RAM constrained m68k system fail to boot or run anything past 6.9-rc4
(sysvinit, not systemd).

As cloud instances multiply, that small quantity of lost RAM gets
multiplied. So it appears that small systems aren't so strange, even after
they become unprofitable...

Yes, who doesn't know the cloud instances with 64 MB RAM. Those are today's standard.

Post by Finn Thain

Post by Michael Schmitz
Much as I appreciate Adrian's efforts to keep up with user space
development, I won't be in a position to help with an ABI change.

Bloated m68k packages will continue to work -- given emulators that run
faster with every hardware upgrade. But how would such a distro add value?

You can easily upgrade Amigas to 256 MB or more these days. The aftermarket
provides a lot of affordable upgrades these days.

Post by Finn Thain
I don't mind if Gentoo ships a separate profile for (downstream) ABI
experimentation, leaving the default m68k profile on the standard ABI.

The Gentoo developers will be glad to hear that you don't mind. Do you think
they need a written permission from you?

Post by Finn Thain
And if Debian wants to switch ABI entirely, I won't object further, I've
said enough about the associated risks.
So I'll just reiterate that I'd rather see more collaboration instead -
1) among all small systems ports, to try to alleviate Debian's package
dependency problem

That dependency chain comes from upstream, not from Debian.

Post by Finn Thain
2) among all developers working on non-commercial architectures, to
improve the GCC Rust frontend

GCC Rust uses parts of the upstream Rust code, so you can expect the same
problems there as well.

Post by Finn Thain
3) among all 680x0 developers interested in the NetBSD ABI

The alignment issue affects NetBSD as well.

Post by Finn Thain
4) among all users of EOL'd hardware, so that value may continue to be
extracted from it (thanks to the efforts of Debian and Gentoo devs,
among others).

Software will run faster with 32-bit alignment, not slower.

Adrian

[Finn Thain]

Post by John Paul Adrian Glaubitz

Post by Finn Thain
3) among all 680x0 developers interested in the NetBSD ABI

The alignment issue affects NetBSD as well.

My experiments showed that my NetBSD/mac68k system aligns int struct
members like my i686 system does.

[John Paul Adrian Glaubitz]

Post by Michael Schmitz
Arnd,

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.

I second that - currently bisecting to find out what makes my extremely
RAM constrained m68k system fail to boot or run anything past 6.9-rc4
(sysvinit, not systemd).

Should extremely RAM-constrained systems be the reference target for m68k?

Post by Michael Schmitz
Much as I appreciate Adrian's efforts to keep up with user space
development, I won't be in a position to help with an ABI change.

Thanks, I will then just do it myself with brute force or drop the port.

Adrian

[Mark D]

Post by John Paul Adrian Glaubitz

Post by Michael Schmitz
Much as I appreciate Adrian's efforts to keep up with user space
development, I won't be in a position to help with an ABI change.

Thanks, I will then just do it myself with brute force or drop the port.
Adrian

Look at it philosophically.  One path is to dig in and try to change as
little as possible to keep the oldest systems working.

The other is to do your best to adapt to keep the greatest relevant to
modern development.

The former is the path (IMHO) towards eventual actions like m68k getting
removed from the kernel entirely.  The latter encourages creative
external efforts like the vampire with 68080 project. Which feeds
current relevance and interest.

So just based on that I think I would want to follow the path that
results in the most modern software compatibility which has the bonus of
reducing friction with upstream developers.

This has been a thing in the Atari/freemint world.  Binutils dropped
a.out support and the platform executable is a hybrid of a.out.  A
clever developer has solved the issue by crafting a hybrid elf format
that is still natively compatible.  This also inches the platform
towards potential shared libraries and virtual memory.  This probably
never would have happened if binutils didn't force the issue.

Fwiw, I love the idea of building with rust, llvm, etc for this
platform.  Maybe the reality is that it will be a non-starter due to
performance and memory requirements caused by the alignment.  I am not
informed enough to judge that.

I'll be quiet again now ;)

Thanks,
Mark

[John Paul Adrian Glaubitz]

Post by Mark D
Look at it philosophically.  One path is to dig in and try to change as
little as possible to keep the oldest systems working.
The other is to do your best to adapt to keep the greatest relevant to
modern development.

This isn't the point. The point is that more and more software requires 4-byte
alignment, even Python requires it these days. We're not talking about nice-to-have
applications but about the fundamentals.

And with more and more software being ported to Rust, the only chance to preserve
the m68k port is to embrace Rust and not to try to fight it. We cannot win such a
fight.

Adrian

[Michael Schmitz]

Adrian,

Post by John Paul Adrian Glaubitz

Post by Michael Schmitz
Arnd,

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.

I second that - currently bisecting to find out what makes my extremely
RAM constrained m68k system fail to boot or run anything past 6.9-rc4
(sysvinit, not systemd).

Should extremely RAM-constrained systems be the reference target for m68k?

I didn't say that - just supporting Arnd's point that much of the RAM
constrained old m68k software won't benefit from today's user space.
Development isn't driven by memory pressure anymore, so code bloat is a
natural consequence.

What such hardware would benefit from is low memory optimized user
space. That's hard to do with Debian, as bloat appears to have crept
into the build dependencies chain (if I understand you correctly). While
Debian was the first Linux distribution to support m68k, these days
there are other options, maybe some better suited to low memory systems
(and I'd consider even 256 MB on Amiga 'low memory' ...).

Post by John Paul Adrian Glaubitz

Post by Michael Schmitz
Much as I appreciate Adrian's efforts to keep up with user space
development, I won't be in a position to help with an ABI change.

Thanks, I will then just do it myself with brute force or drop the port.

Sure, you do pretty much all the work on Debian/68k, so you get to decide.

If this involves changes at kernel level (syscall parameter alignment?)
however, my recommendation would be to rather drop the port than end up
with new kernels no longer backwards compatible with old user space.

Otherwise, I'd not even be in a position to do any kernel testing and
bugfixing (which often requires hardware, not emulators).

Cheers,

    Michael

Post by John Paul Adrian Glaubitz
Adrian

[John Paul Adrian Glaubitz]

Post by Michael Schmitz
I didn't say that - just supporting Arnd's point that much of the RAM
constrained old m68k software won't benefit from today's user space.

We're talking about an open source stack here. No one is going to run an
old binary from the 80s on a current system. And if you want to run old
software, you're certainly also not running the latest kernel.

Post by Michael Schmitz
Development isn't driven by memory pressure anymore, so code bloat is a
natural consequence.

But we're not really suffering from bloat. On the contrary, both software
like systemd or Rust-compiled software actually use less memory, not more.

SysVInit uses a huge set of bash scripts where every action involves spawning
a new shell while systemd does all of that in C. Compiled C code is definitely
faster on an m68k machine than hundreds of shell scripts.

Post by Michael Schmitz
What such hardware would benefit from is low memory optimized user
space. That's hard to do with Debian, as bloat appears to have crept
into the build dependencies chain (if I understand you correctly).

The build dependencies don't end up on the installed system. For example, if
Java code is used to generate documentation, the Java runtime won't have to
be installed on the target machine. But you still need a working OpenJDK
to be able to build such packages.

Post by Michael Schmitz
While Debian was the first Linux distribution to support m68k, these days
there are other options, maybe some better suited to low memory systems
(and I'd consider even 256 MB on Amiga 'low memory' ...).

Again, the problem is not Debian-specific. Heck, it's not even Linux-specific.

Post by Michael Schmitz

Post by John Paul Adrian Glaubitz

Post by Michael Schmitz
Much as I appreciate Adrian's efforts to keep up with user space
development, I won't be in a position to help with an ABI change.

Thanks, I will then just do it myself with brute force or drop the port.

Sure, you do pretty much all the work on Debian/68k, so you get to decide.
If this involves changes at kernel level (syscall parameter alignment?)
however, my recommendation would be to rather drop the port than end up
with new kernels no longer backwards compatible with old user space.
Otherwise, I'd not even be in a position to do any kernel testing and
bugfixing (which often requires hardware, not emulators).

I don't buy this argument. Why would your world fall apart if we switch
alignment to 4 bytes. I seriously don't get it.

Adrian

[John Paul Adrian Glaubitz]

Post by John Paul Adrian Glaubitz

Post by Michael Schmitz
Sure, you do pretty much all the work on Debian/68k, so you get to decide.
If this involves changes at kernel level (syscall parameter alignment?)
however, my recommendation would be to rather drop the port than end up
with new kernels no longer backwards compatible with old user space.
Otherwise, I'd not even be in a position to do any kernel testing and
bugfixing (which often requires hardware, not emulators).

I don't buy this argument. Why would your world fall apart if we switch
alignment to 4 bytes. I seriously don't get it.

If your concern is that you won't be able to build a small userspace anymore,
then you should keep in mind that you will always be able to do that with the
help of Buildroot or Toybox.

FWIW, the suggestion to update the kernel ABI came from Geert, not from me.

Adrian

[John Paul Adrian Glaubitz]

Post by John Paul Adrian Glaubitz
But we're not really suffering from bloat. On the contrary, both software
like systemd or Rust-compiled software actually use less memory, not more.

Well, systemd is completely useless on every 68030 and 68040 Mac that I
own, even ones that have enough memory to run it (e.g. SE/30, IIfx and
Centris 650). It takes most of its time just telling me about all of the
things that are timing out. It fires off too many concurrrent processes
that overwhelm slow CPUs. Whenever systemd becomes a hard requirement in
Debian, I won't be using Debian at all (there are still GNU/Linux
distributions such as Gentoo that do not require systemd).

If you really do not want to use systemd and need something small, you can
just build yourself a chroot using Buildroot or Toybox.

Post by John Paul Adrian Glaubitz
SysVInit uses a huge set of bash scripts where every action involves spawning
a new shell while systemd does all of that in C. Compiled C code is definitely
faster on an m68k machine than hundreds of shell scripts.

Yes, compiled C code is faster than an equivalent script, but scripts
are much easier (for some of us) to edit and turn on and off than
systemd components.

systemctl disable foo.service is too hard?

Plus systemd has lots of components and does lots of things that arguably
an init system shouldn't even be doing, things that aren't needed at all
on old systems, such as managing logins, setting the time and managing DNS.

Old systems don't need user management or networking?

FWIW, these components can be turned off if you insist using a separate package
for each and every standard service that's part of the standard Linux userland.

You are not forced to use systemd components.

Systemd even complains if I manually edit /etc/fstab.

Which is a good thing. SysVInit systems would just silently fail when you added
an entry to /etc/fstab which didn't work properly so that you could end up with
something not being mounted where it should be or vice versa.

Ignoring such failures provokes data loss. That's *not* a good thing.

Perhaps there are ways to tune systemd for small systems,
but I haven't seen any distribution that does that. On small, static
systems that don't have USB, Firewire, PC-Cards, etc., udevd and
sometimes dbus aren't even needed, and systemd is certainly overkill for
such systems.

I'm using systemd on my Amiga and any other embedded system I have and it works.

I'm not trying to rehash old systemd/sysvinit discussions; I realize
that Debian has chosen systemd as its default init system. That's fine;
Debian can do whatever they want, but no one can tell me that systemd,
at least in the configuration as it is distributed by Debian, is better
than sysvinit for small, mostly static systems. That's why there are
entire distributions that are dedicated specifically to not forcing
their users to use systemd.

You mean "professional" distributions like Devuan?

https://lwn.net/Articles/786593/

Post by John Paul Adrian Glaubitz

Post by Michael Schmitz
What such hardware would benefit from is low memory optimized user
space. That's hard to do with Debian, as bloat appears to have crept
into the build dependencies chain (if I understand you correctly).

The build dependencies don't end up on the installed system. For example, if
Java code is used to generate documentation, the Java runtime won't have to
be installed on the target machine. But you still need a working OpenJDK
to be able to build such packages.

Post by Michael Schmitz
While Debian was the first Linux distribution to support m68k, these days
there are other options, maybe some better suited to low memory systems
(and I'd consider even 256 MB on Amiga 'low memory' ...).

Well, I'd consider 16 MiB to be "low memory" for 68030 Macs, but you are
the Debian m68k port maintainer so you can consider whatever you want to
be low memory. Hopefully the bloat (Linux kernel and applications) will
be minimized so that old Macs, such as 68030 PowerBooks and desktops
that can have no more than 36 MiB, will be able to continue running, not
just Amigas that have 256 MiB memory. If we're headed toward Linux
distributions that can only run well enough in QEMU or Aranym, what's
the point in having old systems at all?

First of all, you can still and will always be able to build yourself a tiny
chroot using Buildroot or Toybox. And, secondly, what's the point of running
the latest and greatest kernel on a system which can't make use of any modern
kernel features anyway?


Adrian

[Geert Uytterhoeven]

Post by John Paul Adrian Glaubitz

Post by John Paul Adrian Glaubitz

Post by John Paul Adrian Glaubitz

Post by John Paul Adrian Glaubitz
SysVInit uses a huge set of bash scripts where every action involves

spawning

Post by John Paul Adrian Glaubitz

Post by John Paul Adrian Glaubitz
a new shell while systemd does all of that in C. Compiled C code is definitely
faster on an m68k machine than hundreds of shell scripts.

Yes, compiled C code is faster than an equivalent script, but scripts
are much easier (for some of us) to edit and turn on and off than
systemd components.

systemctl disable foo.service is too hard?

Yes, it's too hard. And if I want to change something in foo.service
instead of disabling it, I'm sure there's a way to do that in systemd as
well, but using vi (or nano) to edit the equivalent sysvinit script is
easier for some of us. Also, if fubar.service is completely messed up,
then I might not be able to boot into the operating system that is
running systemd in order to use systemctl (especially on a slow system).

That's also my experience: when it fails, in 50% of the cases the
system doesn't boot sufficiently far to use systemctl.

But all of that is irrelevant for an alignment discussion...

Gr{oetje,eeting}s,

Geert

[Thorsten Glaser]

(please keep my debian.org address in the distribution list,
not the mirbsd one, as it has better chance to interact with
other mail providers out there for this=E2=80=A6 except Googlemail,
which, of course, is no proper mail provider and actively
disrecommended because it fails to collaborate for FOSS work)

Post by John Paul Adrian Glaubitz

Post by Michael Schmitz
I didn't say that - just supporting Arnd's point that much of the RAM
constrained old m68k software won't benefit from today's user space.

We're talking about an open source stack here. No one is going to run an
old binary from the 80s on a current system. And if you want to run old
software, you're certainly also not running the latest kernel.

Indeed.

We should consider something with 256 MiB RAM the =E2=80=9Cdefault=E2=80=9D
(which also matches the usual =E2=80=9Csmallest VM=E2=80=9D; there are VMs
with just 128 MiB RAM, but even just running apt-get update
can stretch them to swap) and, perhaps, try to keep systems
with 64 MiB working, perhaps with custom kernels. But 256 MiB
is plenty for a normal OSS stack (i.e. no dbus/systemd, proper
classical init), without X11 anyway, but perhaps even with it.

Post by John Paul Adrian Glaubitz
SysVInit uses a huge set of bash scripts where every action involves spawn=

ing

sh scripts, mksh=E2=80=99s /bin/lksh gives a 3=C3=97 speedup, compared to
GNU bash, here, probably even more, as it=E2=80=99s statically linked.

[ low memory ]

Post by John Paul Adrian Glaubitz
Again, the problem is not Debian-specific. Heck, it's not even Linux-speci=

fic.

ACK.

Post by John Paul Adrian Glaubitz

Post by Michael Schmitz
If this involves changes at kernel level (syscall parameter alignment?)
however, my recommendation would be to rather drop the port than end up
with new kernels no longer backwards compatible with old user space.

I don=E2=80=99t buy this.

But, as has been pointed out, if we make the current alignment explicit
everywhere, the kernel ABI does not have to change=C2=B9. And new syscalls,
ioctls, structs, etc. can just be made with natural alignment in mind
(I bet most are already anyway) and with padding assumptions made expli=E2=
=80=90
cit (which again probably is done already anyway).

=E2=91=A0 not for the userspace ABI to change, anyway; that can be decouple=
d
is the point here

bye,
//mirabilos
--=20
11:56=E2=8E=9C=C2=ABliwakura:#!/bin/mksh=C2=BB also, i wanted to add mksh t=
o my own distro =E2=94=82
i was disappointed that there is no makefile =E2=94=82 but somehow the Buil=
d.sh is
the least painful built system i've ever seen =E2=94=82 honours CC, {CPP,C,=
LD}FLAGS
properly =E2=94=82 looks cleary like done by someone who knows what they ar=
e doing

[Finn Thain]

Post by Thorsten Glaser
But, as has been pointed out, if we make the current alignment explicit
everywhere, the kernel ABI does not have to change¹. And new syscalls,
ioctls, structs, etc. can just be made with natural alignment in mind (I
bet most are already anyway) and with padding assumptions made expli‐
cit (which again probably is done already anyway).

Yes, upstream developers can be expected accept patches that make explicit
the alignment of struct members. That's what I've been saying for years.

Luckily, that doesn't require a new ABI. It does require volunteers who
are willing to write and submit patches for those packages that matter to
users.

And that is the real problem: the manpower shortage. The only solution I
proposed for that problem was better collaboration and better allocation
of resources. But his straight-forward request for assistance was an
excellent idea of Adrian's:
https://lists.debian.org/debian-68k/2024/11/msg00007.html

[Geert Uytterhoeven]

Hi Adrian,

On Wed, Nov 13, 2024 at 8:55 PM John Paul Adrian Glaubitz

Post by John Paul Adrian Glaubitz

Post by Michael Schmitz
Development isn't driven by memory pressure anymore, so code bloat is a
natural consequence.

But we're not really suffering from bloat. On the contrary, both software

No, we're not. Kernel images don't grow ca. 25 KiB per kernel release,
and web browsers still run fine in 16 MiB ;-)

Post by John Paul Adrian Glaubitz
like systemd or Rust-compiled software actually use less memory, not more.

Last May, systemd in Debian/sid required me to enable CONFIG_CGROUPS and
CONFIG_DEBUG_FS. Last weekend, I had to add CONFIG_USER_NS.
Yes, that's a small drop in the kernel sea, but all drops count.

Post by John Paul Adrian Glaubitz

Post by Michael Schmitz
While Debian was the first Linux distribution to support m68k, these days
there are other options, maybe some better suited to low memory systems
(and I'd consider even 256 MB on Amiga 'low memory' ...).

How many m68k systems actually have 256 MiB of RAM?

Gr{oetje,eeting}s,

Geert