On Fri, Nov 22, 2024 at 09:45:52AM +0000, Lorenzo Stoakes wrote:
On Thu, Nov 21, 2024 at 11:22:58AM -0800, Guenter Roeck wrote:
On Thu, Nov 21, 2024 at 11:08:54AM -0800, Guenter Roeck wrote:
On Thu, Nov 21, 2024 at 07:50:33PM +0100, Geert Uytterhoeven wrote:
On Thu, Nov 21, 2024 at 7:30 PM Guenter Roeck <linux@xxxxxxxxxxxx> wrote:
On Thu, Nov 21, 2024 at 09:23:28AM -0800, Christoph Lameter (Ampere) wrote:
On Thu, 21 Nov 2024, Geert Uytterhoeven wrote:
Linux has supported m68k since last century.
Yeah I fondly remember the 80s where 68K systems were always out of reach
for me to have. The dream system that I never could get my hands on. The
creme de la creme du jour. I just had to be content with the 6800 and
6502 processors. Then IBM started the sick road down the 8088, 8086
that led from crap to more crap. Sigh.
Any new such assumptions are fixed quickly (at least in the kernel).
If you need a specific alignment, make sure to use __aligned and/or
appropriate padding in structures.
And yes, the compiler knows, and provides __alignof__.
How do you deal with torn reads/writes in such a scenario? Is this UP
only?
Linux does not support (rate) SMP m68k machines.
s/rate/rare/
Ah. Ok that explains it.
Do we really need to maintain support for a platform that has been
obsolete for decade and does not even support SMP?
Since this keeps coming up, I think there is a much more important
question to ask:
Do we really need to continue supporting nommu machines ? Is anyone
but me even boot testing those ?
Not all m68k platform are nommu.
Yes, I wasn't trying to point to m68k, but to nommu in general.
For some more context: I think it is highly unlikely that anyone is really
using a recent version of Linux on a nommu machine. Maybe that was the case
10 or 20 years ago, but nowadays there are other operating systems which are
much better suited than Linux for such systems. Yet, there is a _lot_ of
nommu code in the kernel. In comparison, supporting m68k (mmu based) is a no
brainer, plus there are actually people like Geert actively supporting it.
If we are talking about dropping m68k support, we should really talk about
dropping nommu support first to get some _real_ benefit.
Guenter
I couldn't agree more re: nommu, it is the real source of maintenance
issues at least for us in mm, and one I've personally run into many times.
An aside, but note that there is a proposal to add nommu support to UML,
which would entirely prevent our ability to eliminate it [0] (though it
would make testing it easier! :)
[0]:https://lore.kernel.org/all/cover.1731290567.git.thehajime@xxxxxxxxx/
To update, some interesting discussion in this thread suggests that indeed,
there is an ongoing need for nommu regardless [1].
In which case this nommu uml series is rather helpful for testing :)
[1]:https://lore.kernel.org/linux-mm/09060fcf-47e4-424f-9ab7-ee2f7919dbf5@lucifer.local/T/#m0cb0ace28f3905182369790ddc1b494d408587b9
