Hi Eero,
On Mon, 23 Jun 2025 at 00:13, Eero Tamminen wrote:
> On 16.6.2025 18.39, John Paul Adrian Glaubitz wrote:
> > To summarize:
> >
> > - the ELF header provides provides the e_ident and e_flags fields which
> > could be
> >used for identifying a Linux/m68k system using the 4 bytes alig
Hi,
On Mon, 2025-06-23 at 01:13 +0300, Eero Tamminen wrote:
> On 16.6.2025 18.39, John Paul Adrian Glaubitz wrote:
> > To summarize:
> >
> > - the ELF header provides provides the e_ident and e_flags fields which
> > could be
> >used for identifying a Linux/m68k system using the 4 bytes alig
Hi,
On 16.6.2025 18.39, John Paul Adrian Glaubitz wrote:
To summarize:
- the ELF header provides provides the e_ident and e_flags fields which could be
used for identifying a Linux/m68k system using the 4 bytes alignment ABI
- MIPS uses e_flags for differentiating its ABIs
- PA-RISC sets e_i
> On Jun 18, 2025, at 10:56 PM, Greg Ungerer wrote:
>
> Granted many ColdFire platforms are short on RAM. Size is a problem.
> New versions of packages almost always get larger, that is an on-going
> problem. Heck even version to version kernel bloat is a problem.
> Especially as the years go o
On 19/6/25 15:31, Finn Thain wrote:
On Thu, 19 Jun 2025, Greg Ungerer wrote:
On 19/6/25 08:29, Finn Thain wrote:
On Wed, 18 Jun 2025, Greg Ungerer wrote:
It's not really necessary to enforce this on Coldfire. However,
since buildroot builds completely from source, it wouldn't even be a
pro
On Thu, 19 Jun 2025, Greg Ungerer wrote:
> On 19/6/25 08:29, Finn Thain wrote:
>
> > On Wed, 18 Jun 2025, Greg Ungerer wrote:
> >
> >>> It's not really necessary to enforce this on Coldfire. However,
> >>> since buildroot builds completely from source, it wouldn't even be a
> >>> problem to
On 19/6/25 08:29, Finn Thain wrote:
On Wed, 18 Jun 2025, Greg Ungerer wrote:
It's not really necessary to enforce this on Coldfire. However, since
buildroot builds completely from source, it wouldn't even be a problem
to change the alignment there as well.
Yes, that is totally right in m
On Wed, 18 Jun 2025, Greg Ungerer wrote:
>
> > It's not really necessary to enforce this on Coldfire. However, since
> > buildroot builds completely from source, it wouldn't even be a problem
> > to change the alignment there as well.
>
> Yes, that is totally right in my experience. Certainl
On Wed, 18 Jun 2025, John Paul Adrian Glaubitz wrote:
> On Wed, 2025-06-18 at 13:50 +1000, Finn Thain wrote:
> > > How is messing with a hobbyist project "harmful" in any way? That makes
> > > no sense.
> > >
> >
> > If your port was a pure hobbyist project, you would never have brought
> >
On Wed, 18 Jun 2025, John Paul Adrian Glaubitz wrote:
> On Wed, 2025-06-18 at 13:19 +1000, Finn Thain wrote:
>
> > Do you know of a good solution for this open bug?
> > https://sourceware.org/bugzilla/show_bug.cgi?id=30273
>
> The proper solution would be to actually adhere to the official SVR
Hi Geert,
On 18/6/25 22:54, Geert Uytterhoeven wrote:
Hi Adrian,
On Wed, 18 Jun 2025 at 14:27, John Paul Adrian Glaubitz
wrote:
On Wed, 2025-06-18 at 22:21 +1000, Greg Ungerer wrote:
Could you please elaborate this a bit more, please?
Coldfire is handled as a separate target via TARGET_COLD
On Wed, 2025-06-18 at 14:54 +0200, Geert Uytterhoeven wrote:
> > True, but you won't be able to run any classic m68k binaries on ColdFire
> > and the other way around, are you?
>
> IIIRC if you use a proper subset of the user mode instructions, you
> can create binaries that run on both.
OK, but
Hi Adrian,
On Wed, 18 Jun 2025 at 14:27, John Paul Adrian Glaubitz
wrote:
> On Wed, 2025-06-18 at 22:21 +1000, Greg Ungerer wrote:
> > > Could you please elaborate this a bit more, please?
> > >
> > > Coldfire is handled as a separate target via TARGET_COLDFIRE in GCC, so we
> > > would certainly
Hi Adrian,
On 18/6/25 20:04, John Paul Adrian Glaubitz wrote:
Hello Geert,
On Wed, 2025-06-18 at 11:56 +0200, Geert Uytterhoeven wrote:
Coldfire already uses a different alignment (for the stack):
/* ColdFire and fido strongly prefer a 32-bit aligned stack. */
#define PREFERRED_STACK_BOUNDAR
Hi Greg,
On Wed, 2025-06-18 at 22:21 +1000, Greg Ungerer wrote:
> > Could you please elaborate this a bit more, please?
> >
> > Coldfire is handled as a separate target via TARGET_COLDFIRE in GCC, so we
> > would certainly be able to toggle the alignment settings independent of
> > what's done on
On Wed, 18 Jun 2025, John Paul Adrian Glaubitz wrote:
>
> I would like to lead a discussion ...
>
I would like to read a patch ...
Hello Geert,
On Wed, 2025-06-18 at 11:56 +0200, Geert Uytterhoeven wrote:
> > Coldfire already uses a different alignment (for the stack):
> >
> > /* ColdFire and fido strongly prefer a 32-bit aligned stack. */
> > #define PREFERRED_STACK_BOUNDARY \
> > ((TARGET_COLDFIRE || TARGET_FIDOA) ? 32
Hi Adrian,
On Wed, 18 Jun 2025 at 11:49, John Paul Adrian Glaubitz
wrote:
> On Wed, 2025-06-18 at 11:36 +0200, Geert Uytterhoeven wrote:
> > > I only know about Gentoo and Debian and both want to make the switch.
> >
> > Buildroot? Which is probably where the real product users (using Coldfire)
>
On Wed, 2025-06-18 at 11:36 +0200, Geert Uytterhoeven wrote:
> > I only know about Gentoo and Debian and both want to make the switch.
>
> Buildroot? Which is probably where the real product users (using Coldfire)
> are hiding...
Coldfire already uses a different alignment (for the stack):
/* Co
Hi Adrian,
On Wed, 18 Jun 2025 at 11:16, John Paul Adrian Glaubitz
wrote:
> On Wed, 2025-06-18 at 13:50 +1000, Finn Thain wrote:
> > > How is messing with a hobbyist project "harmful" in any way? That makes
> > > no sense.
> >
> > If your port was a pure hobbyist project, you would never have bro
On Wed, 2025-06-18 at 13:50 +1000, Finn Thain wrote:
> > How is messing with a hobbyist project "harmful" in any way? That makes
> > no sense.
> >
>
> If your port was a pure hobbyist project, you would never have brought
> your complaint to the upstream mailing lists, where developers have to
On Wed, 2025-06-18 at 13:19 +1000, Finn Thain wrote:
> Do you know of a good solution for this open bug?
> https://sourceware.org/bugzilla/show_bug.cgi?id=30273
The proper solution would be to actually adhere to the official SVR4 ABI
when declaring elfosabi == GDB_OSABI_SVR4 and using GDB_OSABI_LI
On Mon, 16 Jun 2025, John Paul Adrian Glaubitz wrote:
[repeated falacies snipped]
>
> How is messing with a hobbyist project "harmful" in any way? That makes
> no sense.
>
If your port was a pure hobbyist project, you would never have brought
your complaint to the upstream mailing lists, w
On Mon, 16 Jun 2025, Jason Thorpe wrote:
>
> > On Jun 16, 2025, at 2:10 AM, Laurent Vivier wrote:
> >
> > I think you need to change the ABI type in the ELF header:
> > https://fr.wikipedia.org/wiki/Executable_and_Linkable_Format
>
> 4-byte alignment binaries should have ELFOSABI_SYSV (0) (s
On Tue, 2025-06-17 at 13:21 +0200, Geert Uytterhoeven wrote:
> > I'm not sure how this is relevant at all. What is the gross profit of the
> > NetBSD organization?
>
> IOW, you can have plenty of ABIs, if you have the manpower to create
> and maintain them.
Both Debian and Gentoo want to maintai
Hi Adrian,
On Tue, 17 Jun 2025 at 12:13, John Paul Adrian Glaubitz
wrote:
> On Tue, 2025-06-17 at 11:59 +0200, Geert Uytterhoeven wrote:
> > > What's keeping us from creating an ABI v2 using either e_ident or e_flags
> > > from the ELF
> > > header so that we can fix also all the other packages
On Tue, 2025-06-17 at 11:59 +0200, Geert Uytterhoeven wrote:
> > What's keeping us from creating an ABI v2 using either e_ident or e_flags
> > from the ELF
> > header so that we can fix also all the other packages that don't work like
> > Javascript?
> >
> > If MIPS can have a plethora of update
Hi Adrian,
On Tue, 17 Jun 2025 at 11:48, John Paul Adrian Glaubitz
wrote:
> On Tue, 2025-06-17 at 09:40 +0200, Geert Uytterhoeven wrote:
> > > What's going to happen when Rust code becomes mandatory in key parts of
> > > the kernel
> > > and then we're unable to build it because we insisted on k
On Tue, 2025-06-17 at 09:40 +0200, Geert Uytterhoeven wrote:
> > What's going to happen when Rust code becomes mandatory in key parts of the
> > kernel
> > and then we're unable to build it because we insisted on keeping the 2 byte
> > ABI?
>
> We fix Rust? ;-)
What's keeping us from creating a
Hi John,
On Wed, 21 May 2025 at 04:15, John Klos wrote:
> Should Linux maintain a 32 bit platform that has alignment issues because
> programmers make bad assumptions?
Linux (the kernel) does maintain it, and bug fixes are backported
to stable trees. The upstream kernel (outside the arch/m68k d
Hi Adrian,
On Tue, 17 Jun 2025 at 09:25, John Paul Adrian Glaubitz
wrote:
> On Tue, 2025-06-17 at 09:02 +0200, Geert Uytterhoeven wrote:
> > On Wed, 21 May 2025 at 04:15, John Klos wrote:
> > > Should Linux maintain a 32 bit platform that has alignment issues because
> > > programmers make bad a
Hi Geert,
On Tue, 2025-06-17 at 09:02 +0200, Geert Uytterhoeven wrote:
> On Wed, 21 May 2025 at 04:15, John Klos wrote:
> > Should Linux maintain a 32 bit platform that has alignment issues because
> > programmers make bad assumptions?
>
> Linux (the kernel) does maintain it, and bug fixes are b
Hi Geert,
On Mon, 2025-06-16 at 14:29 +0200, Geert Uytterhoeven wrote:
> Hi Adrian,
>
> On Mon, 16 Jun 2025 at 14:21, John Paul Adrian Glaubitz
> wrote:
> > I wrote that message on Friday. Odd that your email client claims it was
> > sent today.
> > Besides that, I would like to point again at
Hi Jason,
On Mon, 2025-06-16 at 07:43 -0700, Jason Thorpe wrote:
> > On Jun 16, 2025, at 2:10 AM, Laurent Vivier wrote:
> >
> > I think you need to change the ABI type in the ELF header:
> > https://fr.wikipedia.org/wiki/Executable_and_Linkable_Format
>
> 4-byte alignment binaries should have E
> On Jun 16, 2025, at 2:10 AM, Laurent Vivier wrote:
>
> I think you need to change the ABI type in the ELF header:
> https://fr.wikipedia.org/wiki/Executable_and_Linkable_Format
4-byte alignment binaries should have ELFOSABI_SYSV (0) (since that ABI spec is
where the 4 byte alignment comes f
> On Jun 16, 2025, at 4:01 AM, John Paul Adrian Glaubitz
> wrote:
>
> Strictly speaking, a value of 0x00 indicates SysV ABI [1].
>
> But maybe we could use 0x03 for Linux/m68k with 4 bytes alignment.
I mean, that would be wrong, but if you’ve been pained into a corner...
-- thorpej
Hi Adrian,
On Mon, 16 Jun 2025 at 14:21, John Paul Adrian Glaubitz
wrote:
> I wrote that message on Friday. Odd that your email client claims it was sent
> today.
> Besides that, I would like to point again at what John Klos wrote in reply to
> Finn [1].
The increased email traffic during the
Hello Geert,
On Mon, 2025-06-16 at 13:54 +0200, Geert Uytterhoeven wrote:
> On Mon, 16 Jun 2025 at 13:48, John Paul Adrian Glaubitz
> wrote:
> > On Thu, 2025-06-12 at 08:25 +, Administrator @ R·V·E wrote:
> > > Thanks for your great hard work and efforts to mantain the various and now
> > > c
Hi Adrian,
On Mon, 16 Jun 2025 at 13:48, John Paul Adrian Glaubitz
wrote:
> On Thu, 2025-06-12 at 08:25 +, Administrator @ R·V·E wrote:
> > Thanks for your great hard work and efforts to mantain the various and now
> > considered exotic architectures running Debian, Adrian!
>
> Thanks, and yo
On 16/06/2025 13:10, John Paul Adrian Glaubitz wrote:
On Mon, 2025-06-16 at 13:05 +0200, Laurent Vivier wrote:
I think an e_flags with a new value like EF_M68K_ABI2 would be more appropriate.
How is it currently used on m68k and does QEMU use it? I think that would be
certainly a way to go.
On Mon, 2025-06-16 at 13:10 +0200, John Paul Adrian Glaubitz wrote:
> On Mon, 2025-06-16 at 13:05 +0200, Laurent Vivier wrote:
> > I think an e_flags with a new value like EF_M68K_ABI2 would be more
> > appropriate.
>
> How is it currently used on m68k and does QEMU use it? I think that would be
On Mon, 2025-06-16 at 13:05 +0200, Laurent Vivier wrote:
> I think an e_flags with a new value like EF_M68K_ABI2 would be more
> appropriate.
How is it currently used on m68k and does QEMU use it? I think that would be
certainly a way to go.
FWIW, I checked EI_OSABI on hppa out of curiosity:
gl
On 16/06/2025 13:01, John Paul Adrian Glaubitz wrote:
On Mon, 2025-06-16 at 12:07 +0200, Geert Uytterhoeven wrote:
I think you need to change the ABI type in the ELF header:
https://fr.wikipedia.org/wiki/Executable_and_Linkable_Format
Interesting
Does any system actually use ABI (byte 7)
On Mon, 2025-06-16 at 12:07 +0200, Geert Uytterhoeven wrote:
> > I think you need to change the ABI type in the ELF header:
> > https://fr.wikipedia.org/wiki/Executable_and_Linkable_Format
>
> Interesting
>
> Does any system actually use ABI (byte 7) = 3 (Linux)?
> All of
> amd64/arm/arm64/i
Le 16/06/2025 à 12:07, Geert Uytterhoeven a écrit :
Hi Laurent,
On Mon, 16 Jun 2025 at 11:16, Laurent Vivier wrote:
Le 16/06/2025 à 11:00, John Paul Adrian Glaubitz a écrit :
And there will be a problem with binfmt_misc because we can't rely on
the ELF signature to know which qemu-user to
Hi Laurent,
On Mon, 16 Jun 2025 at 11:16, Laurent Vivier wrote:
> Le 16/06/2025 à 11:00, John Paul Adrian Glaubitz a écrit :
> >> And there will be a problem with binfmt_misc because we can't rely on
> >> the ELF signature to know which qemu-user to run, the one with 2byte
> >> alignment or the o
On Mon, 2025-06-16 at 11:10 +0200, Laurent Vivier wrote:
>
> Le 16/06/2025 à 11:00, John Paul Adrian Glaubitz a écrit :
> > > And there will be a problem with binfmt_misc because we can't rely on
> > > the ELF signature to know which qemu-user to run, the one with 2byte
> > > alignment or the one
Le 16/06/2025 à 11:32, John Paul Adrian Glaubitz a écrit :
On Mon, 2025-06-16 at 11:26 +0200, Laurent Vivier wrote:
binfmt_misc doesn't use the sections to select the interpreter, but the
128 first bytes of the file.
I think you need to change the ABI type in the ELF header:
https://fr.wikip
On Mon, 2025-06-16 at 11:26 +0200, Laurent Vivier wrote:
> > > binfmt_misc doesn't use the sections to select the interpreter, but the
> > > 128 first bytes of the file.
> > >
> > > I think you need to change the ABI type in the ELF header:
> > > https://fr.wikipedia.org/wiki/Executable_and_Linkab
Le 16/06/2025 à 11:15, John Paul Adrian Glaubitz a écrit :
On Mon, 2025-06-16 at 11:10 +0200, Laurent Vivier wrote:
Le 16/06/2025 à 11:00, John Paul Adrian Glaubitz a écrit :
And there will be a problem with binfmt_misc because we can't rely on
the ELF signature to know which qemu-user to r
Le 16/06/2025 à 11:00, John Paul Adrian Glaubitz a écrit :
And there will be a problem with binfmt_misc because we can't rely on
the ELF signature to know which qemu-user to run, the one with 2byte
alignment or the one with 4byte alignment?
What about the ELF note [1] that David Brownlee sugg
On Mon, 2025-06-16 at 10:45 +0200, Geert Uytterhoeven wrote:
> The Linux kernel also knows m68k has an alignment of 2 bytes.
Yes, we have identified (some of) these parts yet. I suggested to add a
kernel option for m68k to allow 4 bytes alignment there.
> > > And yet it works without any problems
On Mon, 2025-06-16 at 10:32 +0200, Laurent Vivier wrote:
> Because most of the structures are correctly aligned by default, but
> some of them not. You must run glibc test suite and LTP to be sure there
> is no regression.
Good suggestion, thanks!
> In QEMU, alignment is defined here:
>
> incl
On Mon, 16 Jun 2025 at 10:33, Laurent Vivier wrote:
> Le 16/06/2025 à 10:14, John Paul Adrian Glaubitz a écrit :
> > On Mon, 2025-06-16 at 10:00 +0200, Laurent Vivier wrote:
> >>> Could you point me to these packages which assume 2 bytes alignment? I'm
> >>> genuinely
> >>> interested as I would
Le 16/06/2025 à 10:14, John Paul Adrian Glaubitz a écrit :
On Mon, 2025-06-16 at 10:00 +0200, Laurent Vivier wrote:
Could you point me to these packages which assume 2 bytes alignment? I'm
genuinely
interested as I would like to put these up on the wiki. So far I haven't found
any.
I have
On Mon, 2025-06-16 at 10:00 +0200, Laurent Vivier wrote:
> > Could you point me to these packages which assume 2 bytes alignment? I'm
> > genuinely
> > interested as I would like to put these up on the wiki. So far I haven't
> > found any.
> >
> > I have used Debian's rebootstrap to create an in
Le 16/06/2025 à 09:39, John Paul Adrian Glaubitz a écrit :
You will create the exact same problem you want to fix: we can guess
some softwares are built on linux/m68k with 2byte alignment in mind. So
once the ABI is changed, you'll have to track them to fix them.
Could you point me to these p
On Mon, 2025-06-16 at 08:33 +0200, Laurent Vivier wrote:
>
> Le 14/06/2025 à 09:21, John Paul Adrian Glaubitz a écrit :
> > On Fri, 2025-06-13 at 17:24 +0200, Laurent Vivier wrote:
> > > A stupid question: is this possible to remove from debian the packets
> > > that are broken?
> > > (I'm sorry i
gt; You can't have a stable ABI without consensus.
A stable ABI that is broken. On a hobbyist project.
> You can't improve the long term prospects for the Linux/m68k project until
> you
> understood how it got to where it was when you arrived.
That's sentimental think
Hello Geert,
On Sun, 2025-06-15 at 11:26 +0200, Geert Uytterhoeven wrote:
> Sorry, I didn't know you have to coordinate this with the glibc project.
> But you have to do something to mark it incompatible with older versions...
> IIRC, I saw Debian bumping SO versions before...
It doesn’t really m
Hello Geert,
On Sun, 2025-06-15 at 11:32 +0200, Geert Uytterhoeven wrote:
> This is one of my worries, too.
> The Debian package archive is much larger than the NetBSD one...
Debian builds currently around 11000 source packages on m68k, NetBSD builds
around 6000 packages. However, keep in mind th
Hello David,
On Fri, 2025-06-13 at 17:26 +0100, David Brownlee wrote:
> I think it is generally accepted that this would be a new ABI - a
> little similar to MIPS o32 vs n32, but with the twist that all CPUs
> support the new ABI and the goal would be for the old ABI to be
> entirely replaced.
>
Le 14/06/2025 à 09:21, John Paul Adrian Glaubitz a écrit :
On Fri, 2025-06-13 at 17:24 +0200, Laurent Vivier wrote:
A stupid question: is this possible to remove from debian the packets
that are broken?
(I'm sorry if you already answered to this question).
Sure, we can remove Python on m68k
On Sun, 15 Jun 2025, John Paul Adrian Glaubitz wrote:
>
> Honest question, Finn: Why are you even participating in this discussion
> when you're neither willing to acknowledge the problem nor willing to
> help address it?
>
You and I don't discuss much; you ignore most of what I've said, th
Hi Eero,
On Fri, 13 Jun 2025 at 21:29, Eero Tamminen wrote:
> On 13.6.2025 17.53, John Paul Adrian Glaubitz wrote:
> > On Fri, 2025-06-13 at 17:15 +0300, Eero Tamminen wrote:
> >> Wouldn't next upgrade completely break user's Debian system so it needs
> >> c
Hi Adrian,
On Fri, 13 Jun 2025 at 15:00, John Paul Adrian Glaubitz
wrote:
> On Fri, 2025-06-13 at 14:51 +0200, John Paul Adrian Glaubitz wrote:
> > On Fri, 2025-06-13 at 14:30 +0200, Geert Uytterhoeven wrote:
> > > So you change the default alignment, bump all so-versions in userspace,
> > > but
On Sun, 2025-06-15 at 11:42 +1000, Finn Thain wrote:
> On Sat, 14 Jun 2025, John Paul Adrian Glaubitz wrote:
>
> >
> > Sure, we can remove Python on m68k. But whether it will still be useful
> > after that remains a different question. I would argue we should rather
> > totally drop the port th
On Sat, 2025-06-14 at 11:20 +, John Klos wrote:
> > I don't see in above dir e.g. LLVM or Qt, which were in the Debian 2-byte
> > alignment problems list:
> > https://wiki.debian.org/M68k/Alignment
>
> Our package lists include as much as could be built in a given quarter.
> The current
On Sat, 14 Jun 2025, John Paul Adrian Glaubitz wrote:
>
> Sure, we can remove Python on m68k. But whether it will still be useful
> after that remains a different question. I would argue we should rather
> totally drop the port then because Linux without Python doesn't really
> work these da
I don't see in above dir e.g. LLVM or Qt, which were in the Debian 2-byte
alignment problems list:
https://wiki.debian.org/M68k/Alignment
Our package lists include as much as could be built in a given quarter.
The current quarter has, for example, llvm and clang:
https://cdn.netbsd.
Hi,
On 14.6.2025 10.51, John Paul Adrian Glaubitz wrote:
Here's a list of almost 6000 software packages that build fine on m68k with
4 bytes alignment:
https://cdn.netbsd.org/pub/pkgsrc/packages/NetBSD/m68k/9.0_2023Q4/All/
...
Exactly my point. It works on NetBSD, so I'm not worried about Lin
On Fri, 2025-06-13 at 22:29 +0300, Eero Tamminen wrote:
> I think quite a bit more binaries than just Glibc are needed for Debian
> upgrade tooling to work, but OK.
I have already performed tests with 4 bytes alignment, same applies to
the Gentoo developers.
I assume you have done your tests as
On Fri, 2025-06-13 at 17:24 +0200, Laurent Vivier wrote:
> A stupid question: is this possible to remove from debian the packets
> that are broken?
> (I'm sorry if you already answered to this question).
Sure, we can remove Python on m68k. But whether it will still be useful
after that remains a
On Fri, 13 Jun 2025, ALeX Kazik wrote:
> And I think that the people who keep this running should be able to
> decide the future. But that is only my opinion.
You're quite right, and that's how the process has always worked. The
discussion is mostly spam, given that the question was always go
On Fri, 13 Jun 2025, John Paul Adrian Glaubitz wrote:
>
> I really don't understand why anyone can make such a suggestion and
> think "Yeah, that's completely reasonable to do. Let's completely change
> half of the Debian distribution ..."
But you should completely change half of the Debian
On Fri, 13 Jun 2025, John Paul Adrian Glaubitz wrote:
>
> Do you expect me to patch broken packages into all eternity?
Some volunteers go looking for bugs to fix and problems to solve, but
no-one expects them to do it. Others are getting paid to do it. Most
people simply don't have time for
On Fri, 13 Jun 2025, John Paul Adrian Glaubitz wrote:
>
> Performance was never the main argument. The main argument was
> unbreaking the port. You are moving goal posts which is an indicator
> that you're not interested in leading a fair and unbiased discussion.
>
Linux/m68k is not broken,
On Fri, 13 Jun 2025, John Paul Adrian Glaubitz wrote:
> On Thu, 2025-06-12 at 18:19 +1000, Finn Thain wrote:
> > On Thu, 12 Jun 2025, John Paul Adrian Glaubitz wrote:
> >
> > > On Wed, 2025-06-11 at 20:16 -0700, Stefan Reinauer wrote:
> > > >
> > > > Fixing pthreads would probably go a long wa
On Fri, 13 Jun 2025, John Paul Adrian Glaubitz wrote:
>
> Both you and Finn still seem to miss the point that the current 2 bytes
> alignment path is a dead end and neither you nor Finn have made any
> substantial contributions to keep this path alive.
>
> If you want to keep this path, roll
Hi,
(Updated subject.)
On 13.6.2025 14.22, John Paul Adrian Glaubitz wrote:
On Thu, 2025-06-12 at 17:54 +0300, Eero Tamminen wrote:
(Full m68k Debian is too heavy to boot in reasonable time on machines
that Hatari emulates, due to missing crypto acceleration, but IMHO also
unnecessary for kern
Hi,
On 13.6.2025 17.53, John Paul Adrian Glaubitz wrote:
On Fri, 2025-06-13 at 17:15 +0300, Eero Tamminen wrote:
Wouldn't next upgrade completely break user's Debian system so it needs
complete re-install?
You would need to extract the glibc package manually from my tests.
On Fri, 13 Jun 2025 at 12:55, Geert Uytterhoeven wrote:
>
> Hi Adrian,
>
> On Sat, 7 Jun 2025 at 11:44, John Paul Adrian Glaubitz
> wrote:
> > On Fri, 2025-06-06 at 20:20 +1000, Finn Thain wrote:
> > > Whereas, the ability to use old binaries is proof that we care about rule
> > > #1 don't break
Hi Adrian,
Le 13/06/2025 à 16:53, John Paul Adrian Glaubitz a écrit :
On Fri, 2025-06-13 at 17:15 +0300, Eero Tamminen wrote:
Wouldn't next upgrade completely break user's Debian system so it needs
complete re-install?
You would need to extract the glibc package manually fro
On Fri, 2025-06-13 at 17:15 +0300, Eero Tamminen wrote:
> Wouldn't next upgrade completely break user's Debian system so it needs
> complete re-install?
You would need to extract the glibc package manually from my tests. After that,
upgrading the system should be possible.
.>
And I'm not sure why being able to run old binaries on a retro-computing
architecture
is is so important for some people that they think it justifies making my life
miserable.
Wouldn't next upgrade completely break user's Debian system so it needs
complete re-install?
If tr
Hi,
You're not offering help. You, like Finn as well, are trying to block fixing
a long-standing problem of Linux/m68k without offering any sustainable
alternatives
to fix this problem.
I didn't see anywhere that Eero was blocking or hinting at blocking. I
only saw Eero offering to collect d
Hi John,
On Fri, 2025-06-13 at 13:21 +, John Klos wrote:
> > You're not offering help. You, like Finn as well, are trying to block fixing
> > a long-standing problem of Linux/m68k without offering any sustainable
> > alternatives
> > to fix this problem.
>
> I didn't see anywhere that Eero w
Hi,
I'm only reading here because I installed debian on my Amiga a long
time ago, and just for fun.
And I think that the people who keep this running should be able to
decide the future.
But that is only my opinion.
Alex.
On Fri, 2025-06-13 at 14:51 +0200, John Paul Adrian Glaubitz wrote:
> On Fri, 2025-06-13 at 14:30 +0200, Geert Uytterhoeven wrote:
> > So you change the default alignment, bump all so-versions in userspace,
> > but keep the kernel-userspace ABI the same by adding explicit alignment
> > tags where n
On Fri, 2025-06-13 at 14:30 +0200, Geert Uytterhoeven wrote:
> So you change the default alignment, bump all so-versions in userspace,
> but keep the kernel-userspace ABI the same by adding explicit alignment
> tags where needed? Old binaries keep on working, new binaries join
> the ecosystem of an
Hi Adrian,
On Fri, 13 Jun 2025 at 14:23, John Paul Adrian Glaubitz
wrote:
> On Fri, 2025-06-13 at 14:09 +0200, Geert Uytterhoeven wrote:
> > You are completely ignoring the last sentence I wrote...
>
> Because I am *extremely* tired of people heckling this discussion without
> *helping* me.
>
>
On Fri, 2025-06-13 at 14:09 +0200, Geert Uytterhoeven wrote:
> You mean Python is broken, as it makes assumptions that are not
> guaranteed by the C standard (oops, which one? ;-) ? ;-)
Not just Python but a lot of packages which I have listed here:
https://wiki.debian.org/M68k/Alignment
This do
Hi Adrian,
On Fri, 13 Jun 2025 at 14:00, John Paul Adrian Glaubitz
wrote:
> On Fri, 2025-06-13 at 13:55 +0200, Geert Uytterhoeven wrote:
> > From its inception, Linux/m68k used an ABI compatible with SunOS,
> > which dates back to the MC68000, and was probably the most popular
> > UNIX OS running
Hello Geert,
On Fri, 2025-06-13 at 13:55 +0200, Geert Uytterhoeven wrote:
> "The official(!) ABI"...
>
> Official according to what and to who?
> There are de jure and de facto standards.
>
> There's a lot of discussion and talking next to each other about
> "the ABI", and which ABI applies to w
Hi Adrian,
On Sat, 7 Jun 2025 at 11:44, John Paul Adrian Glaubitz
wrote:
> On Fri, 2025-06-06 at 20:20 +1000, Finn Thain wrote:
> > Whereas, the ability to use old binaries is proof that we care about rule
> > #1 don't break userspace.
>
> Who is "we"? The official(!) ABI says that pointers are s
On Thu, 2025-06-12 at 17:54 +0300, Eero Tamminen wrote:
> Unsubstantiated performance claims are no good. I was offering help in
> substantiating them.
You're not offering help. You, like Finn as well, are trying to block fixing
a long-standing problem of Linux/m68k without offering any sustaina
On Thu, 2025-06-12 at 08:25 +, Administrator @ R·V·E wrote:
> Thanks for your great hard work and efforts to mantain the various and now
> considered exotic architectures running Debian, Adrian!
Thanks, and you're welcome. Unfortunately, some people like Finn and Eero don't
appreciate these ef
On Thu, 2025-06-12 at 18:19 +1000, Finn Thain wrote:
> On Thu, 12 Jun 2025, John Paul Adrian Glaubitz wrote:
>
> > On Wed, 2025-06-11 at 20:16 -0700, Stefan Reinauer wrote:
> > >
> > > Fixing pthreads would probably go a long way. That's where we lost
> > > about half of our performance.
> >
>
On Fri, 2025-06-13 at 13:56 +0300, Eero Tamminen wrote:
> On 13.6.2025 4.36, Finn Thain wrote:
> > And therein lies the rub -- to identify those workloads which should be
> > measured and to afford each one a suitable weight in your decision making.
>
> It's not just workload affecting the results
Hi,
On 13.6.2025 4.36, Finn Thain wrote:
And therein lies the rub -- to identify those workloads which should be
measured and to afford each one a suitable weight in your decision making.
It's not just workload affecting the results; compiler version,
optimization options [1], workload & kern
1 - 100 of 8869 matches
Mail list logo
