Re: Plan needed for switching m68k to 32-bit alignment

[Michael Schmitz <schmitzmic@gmail.com>]

Adrian,

On 14/11/24 01:54, John Paul Adrian Glaubitz wrote:
> On Tue, 2024-10-29 at 07:57 +1300, Michael Schmitz wrote:
>> Arnd,
>>
>> On 25/10/24 22:55, Arnd Bergmann wrote:
>>> 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' ...).

>> 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

>
> Adrian
>