The future of 32-bit support in the kernel

Removing nommu feels wrong to me. Being able to run linux on a simple enough hardware that anybody sufficiently motivated could write an emulator for, help us, as individuals, remain in control. The more complex things are, the less freedom we have.

It's not a well argumented thought, just a nagging feeling.

Maybe we need a simple posix os that would run on a simple open dedicated hardware that can be comprehended by a small group of human beings. A system that would allow communication, simple media processing and productivity.

These days it feels like we are at a tipping point for open computing. It feels like being a frog in hot water.

It is amazing that big endian is almost dead.

It will be relegated to the computing dustbin like non-8-bit bytes and EBCDIC.

Main-core computing is vastly more homogenous than when I was born almost 50 years ago. I guess that's a natural progression for technology.

It seems like it takes just one user using a certain piece of hardware to justify it being supported in the kernel, which is surprising to me. The cost to kernel dev velocity is not weighed more heavily against that?

It's the end of an area, Linux used to be this thing that was running on quite anything and allowing to salvage old computers.

I think that there is a shitload of old desktop and laptop computers from 10 to 15 yrs that are still usable only with a linux distribution and that will not be true anymore.

Now Linux will be in the same lane as osx and windows running after the last shiny new things, and being like: if you want it, buy a new machine that will support it.

Linux has become the dominant operating system for a wide range of devices, even though other options like FreeRTOS or the BSD family seem more specialized. The widespread adoption of Linux suggests that a single, versatile operating system may be more practical than several niche ones. However, the decision to drop support for certain hardware because it complicates maintenance, as seen here, would seem to contradict the benefit of a unified system. I wouldn't be surprised if it really just results in more Linux forks - Android is already at the point of not quite following mainline.

This seems pretty uninformed on the embedded side - the speaker is I'm sure very qualified generally but it sounds like mostly on the server/desktop side of things.

Like on Armv7-M it's said "Nobody is building anything with this kind of hardware now" - this is just wrong to the point of ridiculousness. Thousands of new products will be designed using these microcontrollers and still billions of units will be produced with them in them - now, true that almost none of those will run Linux on those MCUs but it's crazy to say "nobody" is building things with them. Many of course are moving to Armv8-M microcontrollers but those are 32 bit too!

On the Linux side, there are things like the AMD/Xillinx Zynq-7000 series that will be supported for many years to come.

It's not the worst idea in the world to deprecate support for 32-bit x86 but it is not time to remove it for ARM for many years yet.

Aren't 32 systems more power-efficient? It costs less energy to switch 32 transistors than 64.

Funny, I remember 32 bits being 'the future', now it is the distant past. I think they should keep it all around, and keep it buildable. Though I totally understand the pressure to get rid of it I think having at least one one-size-fits-all OS is a very useful thing to have. You never know what the future will bring.

> One other possibility is to drop high memory, but allow the extra physical memory to be used as a zram swap device. That would not be as efficient as accessing the memory directly, but it is relatively simple and would make it possible to drop the complexity of high memory.

Wild, like some kind of virtual cache. Reminds me a bit of the old Macintosh 68k accelerators; sometimes they included their own (faster) memory and you could use the existing sticks as a RAM disk.

I can’t help but wonder if kernel devs realize how much this discussion sounds like something you’d expect from Apple. They are talking about obsoleting hardware not because it’s fundamentally broken, but because it no longer fits neatly into a roadmap. Open source has always been about making hardware outlive commercial interest and let it run long after the hardware vendor abandons it.

I'm pretty shocked to see comments like "the RAM for a 32-bit system costs more than the CPU itself", but open source isn’t supposed to be about market pricing or what’s convenient for vendors; it’s about giving users the freedom to decide what’s worth running.

I understand that maintainers don’t want to drag around unmaintained code forever, and that testing on rare hardware is difficult. But if the code already exists and is working, is it really that costly to just not break it? The kernel's history is full of examples where obscure architectures and configs were kept alive for decades with minimal intervention. Removing them feels like a philosophical shift, especially when modern hardware is more locked down and has a variety of black box systems running behind it like Intel ME and AMD PSP.

So Arnd Bergmann thinks that all future systems, embedded included, will have 64 bit CPUs? Or will embedded just stop using Linux and move to the BSDs?

the netbsd team agrees! more users for us.

i do miss being able to read and memorize hex addresses. 64 bits is a little too long to easily 'see' at a glance. or see at all for that matter.

The Apple Watch has 32-bit memory addressing (and 64-bit integer arithmetic -- it's ILP32). Granted it doesn't run Linux, but it's a very very modern piece of hardware, in production, and very profitable.

Same for WASM -- 32-bit pointers, 64-bit integers.

Both of these platforms have a 32-bit address space -- both for physical addresses and virtual addresses.

Ripping out support for 32-bit pointers seems like a bad idea.

On the userland side, there is some good progress of using thunking to run 32-bit Windows programs in Wine on Linux without the need for 32-bit libraries (the only edge case remaining is thunking 32-bit OpenGL which is lacking needed extensions for acceptable performance). But the same can't be said for a bunch of legacy 32-bit native Linux stuff like games which commonly have no source to rebuild them.

May be someone can develop such thunking for legacy Linux userland.

[dead]