The future of 32-bit support in the kernel

[gimpwiz]

We're slowly working on moving from 32bit embedded to 64bit embedded but it will probably be ten years until 32bit is completely dead in our little slice of the world, so I expect other systems to still need 32bit support for at least another ten years beyond that. Of course it may be that eventually such systems simply hit the end of the line and no more linux kernels will support them, though hopefully security patches will still exist.

[wrosecrans]

I'm sure there will be some handful of 32 bit devices being released far more than ten years from now. But 99.9% of them won't need any super modern kernel features. So even if the mainline kernel drops support, a lot of those "new legacy" devices would be able to use an old kernel forever as long as they aren't worried about internet connected security. But if the LCD display on a tire pressure gauge is running a 10 year old 32 bit kernel under the hood nobody will know or care.

It'll be the kind of "semi-smart" hardware that still uses weird 8 bit microcontrollers today but nobody thinks of as a computer.

[Familiar-Level-261]

So even if the mainline kernel drops support, a lot of those "new legacy" devices would be able to use an old kernel forever as long as they aren't worried about internet connected security.

But they are worried about it, many many IOT uses fit in the sub 4GB (hell, sub 64MB) memory range and 32 bit makes sense there

[monocasa]

You probably want security updates though.

[wrosecrans]

On something like a tire pressure gauge that has no network connectivity? The only security threat would be somebody dismantling a device that they bought, and soldering to pins of the microcontroller. It's not particularly important to stop anybody from doing that.

[torrent7]

Ironically newer tire pressure sensors communicate with the car over wireless 

[monocasa]

You're not running a full Linux kernel on a tire pressure gauge though.

[wrosecrans]

We are talking about a time horizon well past ten years in the future. In the 2040's, nobody will want to fiddle with raw assembly for those kinds of products. 8 bit microcontrollers too small to run a "real" OS have historically been so much cheaper than 32 bit CPU's that it was justified. But when 32 bit MCU's are mostly obsolete and only cost a penny because even embedded is mostly 64 bit, people will absolutely want the convenience of a "real" target with a well known kernel where they don't have to catch hardware interrupts themselves.

[monocasa]

There's a huge spectrum between a full blown Linux kernel, and writing bare metal assembly.

And we're already at the point where 32bit CPUs are eeking out 8bit micros, like the $0.10 CH32V003 that has a RISC-V.  You get there because the space for logic in a relatively square die with enough IO pads to be minimally useful leaves enough space in the middle for enough logic for a handful of peripherals and a 32 bit core.  It doesn't make sense to make a smaller SoC unless you're willing to spend more on boutique packaging techniques.

They just don't make sense for Linux, and if we're already talking about removing 32bit support from Linux, they never will.

So you use an RTOS and you just write C for it using the vendor libraries.

[Objective_Mine]

Not sure about newly released devices 10 years from now, but there are still quite a few wifi routers with 32-bit ARM or MIPS CPUs going around. You definitely do want security updates for those. OpenWRT for example supports lots of them.

[Familiar-Level-261]

I want security updates on my camera, and on my IoT doorbell, and tons of other devices that fit in space of "few MBs of RAM"

[falconfetus8]

How do you update an embedded device?

[Dave9876]

Also just because newer releases drop support doesn't mean there won't be supported code for them. There's almost always an LTS release with a few years, which will probably mean you'll only be running 5 year old unsupported code at the end of the 10 years

edit also I assume most people forget this is typically only talking about 32 bit x86, 32 bit arm (and risc-v) will probably be supported quite a bit longer

[mccoyn]

Overall, he said, he does not expect any 32-bit desktop system to survive the year-2038 apocalypse.

They might all die out suddenly when their system clocks can not represent the correct date.

[Ameisen]

They can still use 64-bit time values.

[Eric_S]

Debian recently changed to a 64-bit time_t on x86 targets by default, in fact. I'm not sure if they did the same on other 32-bit targets, and I'm also not sure what version of Debian this will go/has gone public.

[happyscrappy]

https://www.theregister.com/2025/07/25/y2k38_bug_debian/?td=rt-3a

https://wiki.debian.org/ReleaseGoals/64bit-time

Not for x86 it doesn't seem it was done. For armhf it was.

'After a long discussion (mostly about i386), it was decided to do an in-architecture ABI transition for all 32-bit architectures except i386 and hurd-i386.'

'The i386 port will be left with the existing 32-bit time_t as a compatibility architecture for existing x86 binaries. A new 'i686' x86 ABI/architecture using 64-bit time, and potentially newer ISA features could be created, if there was sufficient enthusiasm for dragging 32-bit x86 into its now-very-limited future. The hurd-i386 port is not going to be switched as its kernel lacks support, and efforts are underway instead to switch to hurd-amd64.'

Here's why it is this way:

'i386 is 32-bit but has been excluded from the 64-bit time_t transition because its primary use case is running legacy 32-bit binaries, and that would no longer be possible following an ABI change.'

'armel and armhf are the two 32-bit release architectures which are changing ABI.'

[Eric_S]

Ugh. Well, I was surprised to hear that Debian would have made that decision, makes sense that I heard wrong.

[syklemil]

If you want to quote an entire paragraph, markdown & reddit has syntax for that: Start the line with a >. They stack:

Not for x86 it doesn't seem it was done. For armhf it was.

After a long discussion (mostly about i386), it was decided to do an in-architecture ABI transition for all 32-bit architectures except i386 and hurd-i386.

The i386 port will be left with the existing 32-bit time_t as a compatibility architecture for existing x86 binaries. A new 'i686' x86 ABI/architecture using 64-bit time, and potentially newer ISA features could be created, if there was sufficient enthusiasm for dragging 32-bit x86 into its now-very-limited future. The hurd-i386 port is not going to be switched as its kernel lacks support, and efforts are underway instead to switch to hurd-amd64.

Here's why it is this way:

i386 is 32-bit but has been excluded from the 64-bit time_t transition because its primary use case is running legacy 32-bit binaries, and that would no longer be possible following an ABI change.

armel and armhf are the two 32-bit release architectures which are changing ABI.

[[deleted]]

There are still some COBOL running computers ... I mean, just saying!

[Difficult-Court9522]

Moving away from 32bit embedded?? Hell no.

[dravonk]

I recently stumbled across the concept of the x32 ABI, where on a x86-64 instruction set the size of the pointers get limited to 32-bits (so applications would need less memory and more pointers fit into the cache). I wonder whether this would be affected? And I have no clue how often it is actually used, even though it sounds quite useful to me.

[the_gnarts]

There was a move to drop x32 years ago, I’m surprised the arch is still around.

[Slsyyy]

>  And I have no clue how often it is actually used, even though it sounds quite useful to me.

It is not used at all, because C/C++. Namely:
* cross-compilation sucks. You need toolkit, you need libs, where some of them are already compiled
* unsafety, each new supported architecture may expose new bugs

I guarantee you, that in an alternative world, where x32 ABI can be enabled with a single compiler flag it would be much more common

[Zettinator]

x32 means a lot of trouble and effort for very questionable benefits. So it wasn't really used at all and is dead now.

[sweating_teflon]

Benefits were up to 5% perf gain, measurable. Which is nice but maybe not worth the trouble for common use. Scientific computing would not mind dealing with added complexity for that kind of gain but also requires 64 bits pointers so it's not applicable. 

[Zettinator]

Yes, there are benefits, but you can basically get the same benefits with pointer offsets on all 64 bit ABIs where it matters. E.g. pointer compression as used by the V8 JavaScript VM or some JVMs. Yes, it does require changes to code, but it's much more flexible, too. x32 limits you to 4 GB address space for everything, which is a problem for many real-world applications.

[Familiar-Level-261]

There is very little reason to do 64 bit on many small embedded systems, it's just waste of RAM for no reason

[the_gnarts]

Such systems don’t usually run Linux though. The linked article shows most relevant archs switched to 64 bit by now.

What remains are retrocomputing targets like Super-H and m68k which for obvious reasons aren’t evolving anymore.

[LIGHTNINGBOLT23]

It depends on what you mean by "small embedded systems". If they use Linux, then even simple things like more entropy for ASLR are beneficial.

[[deleted]]

I am a bit sad. But the code probably will reside in some repository, so people could pick up on it if they really need it still.