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

Hello,

> As I pointed out years ago, you need to stop wasting effort on packages
> that aren't relevant anymore, due to bloat.

There's no real point being made here. Which packages aren't relevant any 
more, due to bloat? Who decides?

> And here's another thing you need to understand: there is no future for a
> port that has no porter willing to identify relevant packages and send
> patches upstream.

This is a non sequitur. Reporting upstream is nice, but a port can exist 
without stuff getting reported upstream.

While Adrian is obviously emotionally committed to improving Linux on 
m68k, the points he makes have reasoning, thought and explanations behind 
them. None of the arguments from you, Finn, make much sense. You're 
talking about irrelevant things and bringing nonsense examples in to the 
discussion. Your examples lack technical merit.

The issue really boils down to this:

Should Linux maintain a 32 bit platform that has alignment issues because 
programmers make bad assumptions?

Your argument is that ABI breakage is death, and that projects and the 
world are better when we tell people to fix their broken code.

I agree that ABI breakage is a huge hurdle. At the same time, the ABI will 
change to fix 32 bit time. Is there any good reason to NOT switch to 32 
bit alignment at the same time the time changes are made? I can't think of 
any reason.

So can we all agree that there's no reason to not change alignment when 
the time changes are done?

Next, I also agree that programmers should not make padding assumptions. 
However, the real world shows us that there are way too many gatekeepers 
who scoff at the idea of supporting anything that's not Arm, amd64, or 
perhaps RISC-V. They don't care if their bad assumptions about floating 
point affect embedded platforms. They don't care if they've assumed that 
nothing of interest ever runs on big endian systems. Heck - they sometimes 
don't even care if things no longer compile or run properly on 32 bit x86!

Dealing with them is tedious. Sometimes a private email to the right 
person in a project leads to a proper fix, and we don't even have to 
publicly talk about the fact that the failure was on m68k, VAX, Alpha, or 
whatever.

I've done enough of this to know that it's far, far better a spend of my 
time to make things work by default where possible, and if not, to 
maintain local patches with an email sent off to good people so the 
gatekeepers can be avoided.

If you think that the work of getting projects to care about edge cases 
isn't hard, then good for you - perhaps you should volunteer to do it. But 
at the same time I've seen you say you don't need and arent interested in 
these fancy new languages and packages, so I can't see you volunteering to 
do it.

So if you're not going to volunteer yourself, then it's not really your 
place to suggest to others that they should be doing it instead of taking 
the easier route, which is to make more things work by default.

> But, if it's not already dead, you will kill Debian/m68k if you break the
> ABI contract.

It's frustrating that you'd write this.

Are there so few fans of m68k that this will kill Debian/m68k? If so, then 
the 64 bit time change will kill Debian/m68k, and there's nothing anyone 
can do about it. So are you saying that the death of Debian/m68k is 
inevitable, and that we should all just give up? Anyone who still wants to 
run a modern OS on m68k hardware can still run NetBSD, after all. Right?

Or maybe this WON'T kill Debian/m68k. And if it won't, then making two ABI 
changes at the same time is no different than making one. Right? So why 
not make the default alignment for m68k fit what programmers, who we all 
agree really shouldn't be assuming, assume for 32 bit so more things Just 
Work?

I see absolutely no compelling reason given by you or anyone else about 
why this shouldn't be done aside from ABI change, and if if the ABI is 
about to change for time, then that reason becomes moot, doesn't it?

Or do you or anyone else have a reason why it's not moot?

> Nevermind removing that characteristic which provides it with a unique
> advantage, being a smaller memory and cache footprint.

This is ridiculous handwaving.

If the memory footprint of software goes up enough to matter because of 32 
bit instead of 16 bit alignment, then perhaps someone should tell people 
running the NetBSD/sun2 port. The very latest NetBSD runs on m68010 
systems with actual 16 bit data busses in 4 megabytes of memory with 32 
bit alignment. Think about all the memory they could save!

Ok. That was a bit snarky, but do you really expect anyone to take this 
seriously?

Likewise, do you really think that the overhead of unaligned access is 
outweighed by the fact that more stuff fits in the cache? Seriously?

> Try to see the big picture. All ports will suffer the same fate as this
> one: fewer users, commercial irrelevance, reluctant contributors and
> bloated packages.

What does any of this have to do with fixing alignment on m68k?

> The relevance of m68k is now the way in which we respond to those
> challenges. If the best that any port can hope for is ABI breakage, we've
> failed.

Are you here advocating for the termination of Debian/m68k? Or are you 
saying that alignment shouldn't be updated, and time shouldn't be updated? 
I really don't understand what you're suggesting.

> One does not age gracefully by pretending to be young. m68k does not
> contribute anything by becoming the same as every other 32-bit big-endian
> platform.

This is nonsense. The natural alignment for m68020, m68030, m68040, m68060 
is 32 bit. That Linux didn't follow the SVR4 spec for ELF was an error.

I really want to know:

Who gets to make the call about whether or not the change is made?

John Klos