From: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
To: Michael Schmitz <schmitzmic@gmail.com>,
Arnd Bergmann <arnd@arndb.de>,
linux-m68k <linux-m68k@vger.kernel.org>
Cc: debian-68k <debian-68k@lists.debian.org>,
James Le Cuirot <chewi@aura-online.co.uk>,
Sam James <sam@gentoo.org>,
Geert Uytterhoeven <geert@linux-m68k.org>,
Andreas Schwab <schwab@linux-m68k.org>,
Thorsten Glaser <tg@mirbsd.de>
Subject: Re: Plan needed for switching m68k to 32-bit alignment
Date: Wed, 13 Nov 2024 20:55:12 +0100 [thread overview]
Message-ID: <31a04ef1ca569580d29ed09097766e385a23044b.camel@physik.fu-berlin.de> (raw)
In-Reply-To: <f87a85b2-809a-44dc-9a61-24698d7888eb@gmail.com>
On Thu, 2024-11-14 at 07:36 +1300, Michael Schmitz wrote:
> 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.
> 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.
> 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.
> 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.
> > > 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
: :' : Debian Developer
`. `' Physicist
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
next prev parent reply other threads:[~2024-11-13 19:55 UTC|newest]
Thread overview: 71+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-25 6:48 Plan needed for switching m68k to 32-bit alignment John Paul Adrian Glaubitz
2024-10-25 9:06 ` Finn Thain
2024-10-25 9:18 ` John Paul Adrian Glaubitz
2024-10-26 7:31 ` Finn Thain
2024-10-26 22:04 ` Thorsten Glaser
2024-10-27 2:49 ` Finn Thain
2024-10-27 3:08 ` Thorsten Glaser
2024-10-27 3:47 ` Finn Thain
2024-10-27 4:23 ` Thorsten Glaser
2024-10-27 6:16 ` Finn Thain
2024-10-27 13:15 ` Arnd Bergmann
2024-10-28 3:07 ` Thorsten Glaser
2024-10-28 4:51 ` Finn Thain
2024-10-28 8:09 ` John Paul Adrian Glaubitz
2024-10-28 8:49 ` Finn Thain
2024-11-13 12:53 ` John Paul Adrian Glaubitz
2024-10-28 8:03 ` John Paul Adrian Glaubitz
2024-10-28 8:44 ` Finn Thain
2024-11-13 12:51 ` John Paul Adrian Glaubitz
2024-10-28 7:58 ` John Paul Adrian Glaubitz
2024-10-28 7:55 ` John Paul Adrian Glaubitz
2024-11-14 16:29 ` Geert Uytterhoeven
2024-11-15 0:24 ` Finn Thain
2024-11-15 1:24 ` Thorsten Glaser
2024-11-15 1:31 ` Thorsten Glaser
2024-10-28 7:53 ` John Paul Adrian Glaubitz
2024-10-28 7:49 ` John Paul Adrian Glaubitz
2024-10-28 7:47 ` John Paul Adrian Glaubitz
2024-10-28 8:40 ` Finn Thain
2024-11-13 12:50 ` John Paul Adrian Glaubitz
2024-11-13 22:01 ` Finn Thain
2024-10-28 7:43 ` John Paul Adrian Glaubitz
2024-10-28 7:40 ` John Paul Adrian Glaubitz
2024-10-28 8:29 ` Finn Thain
2024-11-13 12:47 ` John Paul Adrian Glaubitz
2024-11-13 22:52 ` Finn Thain
2024-10-25 9:55 ` Arnd Bergmann
2024-10-25 10:10 ` John Paul Adrian Glaubitz
2024-10-25 10:50 ` Arnd Bergmann
2024-10-25 15:07 ` Andreas Schwab
2024-10-28 7:24 ` John Paul Adrian Glaubitz
2024-10-25 21:38 ` Thorsten Glaser
2024-10-25 22:24 ` Andreas Schwab
2024-10-25 23:42 ` Thorsten Glaser
2024-10-27 13:03 ` Greg Ungerer
2024-10-27 12:58 ` Arnd Bergmann
2024-10-28 3:19 ` Thorsten Glaser
2024-10-28 3:54 ` Greg Ungerer
2024-10-28 7:57 ` John Paul Adrian Glaubitz
2024-10-28 7:30 ` John Paul Adrian Glaubitz
2024-10-26 10:46 ` Geert Uytterhoeven
2024-10-28 7:41 ` John Paul Adrian Glaubitz
2024-10-28 7:26 ` John Paul Adrian Glaubitz
2024-11-14 19:46 ` Geert Uytterhoeven
2024-11-14 22:13 ` Thorsten Glaser
2024-11-14 22:37 ` James Le Cuirot
2024-10-28 18:57 ` Michael Schmitz
2024-10-29 3:39 ` Finn Thain
2024-11-13 12:58 ` John Paul Adrian Glaubitz
2024-11-13 23:12 ` Finn Thain
2024-11-13 12:54 ` John Paul Adrian Glaubitz
2024-11-13 18:36 ` Michael Schmitz
2024-11-13 19:55 ` John Paul Adrian Glaubitz [this message]
2024-11-13 20:48 ` Stan Johnson
2024-11-13 21:01 ` John Paul Adrian Glaubitz
2024-11-14 18:07 ` Stan Johnson
2024-11-14 19:28 ` Geert Uytterhoeven
2024-11-13 20:49 ` John Paul Adrian Glaubitz
2024-11-13 21:33 ` Thorsten Glaser
2024-11-13 23:34 ` Finn Thain
2024-11-14 19:32 ` Geert Uytterhoeven
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=31a04ef1ca569580d29ed09097766e385a23044b.camel@physik.fu-berlin.de \
--to=glaubitz@physik.fu-berlin.de \
--cc=arnd@arndb.de \
--cc=chewi@aura-online.co.uk \
--cc=debian-68k@lists.debian.org \
--cc=geert@linux-m68k.org \
--cc=linux-m68k@vger.kernel.org \
--cc=sam@gentoo.org \
--cc=schmitzmic@gmail.com \
--cc=schwab@linux-m68k.org \
--cc=tg@mirbsd.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).