LWN: Comments on "The future of 32-bit support in the kernel"

Tired of hostility towards anything that isn't current-gen

mb — Tue, 16 Sep 2025 16:07:47 +0000

>we don't really want to deal with this any more, but if you do, take maintainership

The problem is that these people that take over maintainership basically don't exist. Even if they promise to do so, that rarely actually happens.
That means at the end maintainership for the "old stuff" is left to the normal maintainers.
And that's why they want to get rid of old stuff.

And it goes way beyond that: Keeping old things alive often causes overhead in completely different areas. Especially with things like big-endian support or general 32bit support. Putting maintenance burden on people who have never heard of the "old stuff" that some hobby enthusiast wants to keep going.

You see, if you want to keep ancient stuff running, you can just use an old kernel and/or an old distribution.

Long Term Support - one reason why

Wol — Tue, 16 Sep 2025 09:59:03 +0000

https://en.wikipedia.org/wiki/PDP-11

The last design was released in 1990, production ceased (by DEC) in 1997. "Authorised clones" may have lasted slightly longer. Not bad for a design released in 1970.

Cheers,
Wol

Long Term Support - one reason why

paulj — Tue, 16 Sep 2025 09:32:32 +0000

I bet you can /still/ pay DEC^WHPE large amounts of money and get PDP-11 support - as per a sibling comment, _for sure_ HP still had at least 1 specialised group doing PDP-11 support in 2016 - 2018.

DEC was still _manufacturing_ PDP-11 compatible machines up to around 1995!

Tired of hostility towards anything that isn't current-gen

taladar — Tue, 16 Sep 2025 07:32:45 +0000

Things like 32bit and endianess aren't really the "take maintainership" kind of features though. You have to consider them throughout the whole code base, so it is hard to push maintainership of those features onto the community of people who care (quite independently of the question if that community even has enough volunteers to do the work if you could separate it out).

Also, both of 32bit and big endian have been on a long decline, so this is hardly the first sign that they would eventually be removed.

Embedded systems

ssmith32 — Tue, 16 Sep 2025 02:42:08 +0000

Is it the actual cost of hardware, or certification?

Years ago, I did a brief stint at a company that made fire panels, and was told the main reason not to upgrade was to avoid re-certification.

They actually preferred to attach a proprietary dongle they paid good money for (which talked to Honeywell's cloud, again, more costs) instead of touching anything - hardware or software - on the panel.

The architects and engineers on the hardware side knew it was not the best solution, but the certification costs were just too high.

I'm assuming a lot has changed technically - it's been a long time - but I'd imagine the regulatory costs have not gone down?

Long Term Support - one reason why

farnz — Mon, 15 Sep 2025 11:56:30 +0000

There's still jobs out there based around supporting old binaries on PDP-11s, because updating your compliance certificate for a modification of the existing code on the existing hardware is a small thing, but updating it for new hardware or new code is a big thing.

The nuclear power industry has a chunk of this, for example - you know that the old hardware and software broadly does the right thing, but you need to make a slight change, and it's safer to slightly change the current software on old hardware designs than to rewrite the software or change the hardware significantly. And you paid DEC huge money for copies of PDP-11 schematics, PCB layouts etc, so that you can still manufacture new PDP-11s now that DEC isn't around.

Long Term Support - one reason why

paulj — Mon, 15 Sep 2025 11:41:50 +0000

My first proper job was in the contract support team at DEC. DEC were still supporting PDP 11's - that was maybe around '98 or '99. DEC were also supporting all kinds of weird old Unix boxes from a number of other vendors. I still remember getting a call about some kind of Siemens Unix box - first I knew Siemens ever had their own Unix boxes! Years later, I worked for HP, and... there was still a little group there supporting some app for some particular customer on PDP-11s. That was circa 2016 to 2018!

DEC^WCompaq^WHP enterprise support is a huge business, and some portion of that is charging a *lot* of money supporting weird old shit for a small set of customers who need it and can afford it.

What does 32-bit support in the kernel mean?

arnd — Mon, 15 Sep 2025 11:28:33 +0000

I think when once it gets to removing ARMv7 support, and the rest of 32-bit with it, it's pretty much impossible to add back, as we'd start making assumptions about sizeof(long) and sizeof(void*) being 64-bit everywhere, with very little incentive to keep it portable. The main driver for that may be 128-bit CPU support, which will come eventually based on how address spaces keep growing by roughly the same number of bits every decade. Supporting three different word sizes is going to be much harder than two, so if Linux is going to run on 128-bit CPUs, the time may have come to stop running on 32-bit CPUs.

The reason I did not spend much time on that in the presentation is that this is too far in the future to make any specific predictions. We'll need at least ten more years of ARMv7 support just for the earliest machines that have a planned support life of 25 years like the i.MX6, and there are still new ARMv7 SoCs coming out that need to get updates for at least 10 years. Both of these are really lower bounds based on what I showed in the slide about older embedded targets. If some of the ARMv7 chips are used as long as the ppc8xx series, that would put the end well into the 2040s.

If there are machines that are not supported in mainline but are actively used, the best way to keep them usable in the future is to upstream all patches and keep reporting bugs when things break.

Long Term Support - one reason why

jjs — Sat, 13 Sep 2025 18:02:16 +0000

No idea how things are now, but around 25 years ago, I was working a job that included working with IBM mainframes. From attending conventions and meeting others who had IBM mainframes, some orgs were running 30+ year old binaries on their systems. Often, they had no access to the source code, but that was OK, it did the job, and they could surround it with new software to handle the new things. And if they needed help, they called IBM, who was prepared to support.

Why? Because it worked, and it made them money.

Also saw this with DEC VAX and HP MP/3000 systems. There was a reason these companies maintained such backward compatibility. $$$.

Again, been out of that arena for a long time, no idea current status (other than DEC is gone, HP is split up).

Tired of hostility towards anything that isn't current-gen

awilfox — Sat, 13 Sep 2025 01:52:58 +0000

Articles like this are why I'm still holding on to a patchset I wrote nine months ago that fixes KVM on 32-bit and 64-bit big endian Power. I've sent it to at least a dozen people by now, and all are very happy with it, and it applies to 5.15, 6.6, 6.12, and head. And I don't send it to lkml or kvmppc or linuxppc-dev because I am *terrified* at being the next to be yelled at for "using this old crap". The next to get piled on with hate comments. The next to be vilified by a seeming lynchmob of commenters, arm-chair quarterbacks, and actual kernel developers, all with the goal of driving out anything that cannot be purchased right now. God forbid LWN or Phoronix pick it up and I get actual targeted threats again, like when I made Firefox run on PPC64.

I wrote this KVM patch because it's not "old crap". It's the hardware I use to run Linux. It's the hardware I enjoy running Linux on. When I started using Linux in 1999, the barrier to entry was "do you have the hardware, did you test it, and is the code good quality". Now, the barrier to entry seems to be "is it still sold by the vendor". If I wanted that sort of experience, I would be running Windows.

I've also started working on making Nouveau work on big endian systems again. And the fd.o people were realistic, saying there was probably a lot of issues, and they don't want to spend their time helping me - but if I get somewhere, send them patches, and they'd still happily take them. Why not write articles like *that*? Why not say "we don't really want to deal with this any more, but if you do, take maintainership". Even the Itanium got a question of "does anyone want to take it up" before removal! Or is the idea of supporting big endian and/or 32-bit systems so offensive that even if offered maintainers, you wouldn't want them?

I know Arnd, and I don't think he is quite as hostile as the article comes across. In my experience, he has been lovely to work with. The rest of the kernel maintainers, not so much. And the Internet peanut gallery? The icing on the cake of why I can't bring myself to bother with the kernel any more.

What does 32-bit support in the kernel mean?

jem — Fri, 12 Sep 2025 16:16:16 +0000

The main emphasis in Arnd Bergmann's presentation is on how feasible ending 32-bit support would be, based on how many 32-bit platforms are left to support. I would have liked to hear more info on what 32-bit support in the kernel *is* and what consequences the removal would have, from a technical point of view.

The presentation mentions high memory support and 64-bit time. I understand removing the high memory code would get rid of largely unused cruft, but what else would removing 32-bit support mean? Imagine a hypothetical 32-bit machine with an out-of-tree Linux kernel, with its own set of 32-bit machine specific drivers and core kernel code. How badly would a removal of 32-bit support in the Linux kernel generic ("infrastructure") code suddenly pull the rug from under the feet of the out-of-tree project?

M68k and SuperH are MMU ports!

raven667 — Wed, 10 Sep 2025 03:38:57 +0000

Linux has tried, and succeeded, in being all things to all people on all systems, as much or more than NetBSD but there is a good reason that different projects exist with different goals and focus. Linux is the result of the worlds largest vendors efforts which are coordinated through the Linux Foundation trade consortium, but not every system *needs* to run Linux specifically, a subset of use cases could transition to NetBSD or another similar kernel and provide resources to that project and have both projects be healthier as a result. Vendors with niche CPUs could rally around a system like NetBSD and make the changes they want with less concern they are going to break some use case on billions of peoples devices that they weren't even aware existed.

A world where Linux ran on only 95% of the types of systems it does now, and the other 5% moved to Free/Net/OpenBSD or another kernel, but each group could focus on making their part the best would probably be a good world.

longevity

raven667 — Wed, 10 Sep 2025 03:19:12 +0000

I'm catching up very late but as a practical matter, unless you are letting people run new custom code on the system and need to protect against attacks from local users, there are a lot of cases where the security issues of the Linux kernel just don't matter. The kernel embedded inside of an ethernet switch probably doesn't matter near as much as the implementation of ssh, ospf/bgp, arp, or a web interface, anything that gives shell access to the embedded system is a bigger problem than a local vulnerability in the system, as that's not the security boundary the system is trying to enforce, everything could be running as root with filesystem perms of 777 in some embedded use cases ;-).

64-bit big-endian

anton — Tue, 09 Sep 2025 20:58:10 +0000

IBM switched their Linux support for Power to little-endian, when introducing OpenPower (Power 8 or Power 9). They completely dropped support for big-endian AFAICT, and other people seem to have picked up that attitude, too.

Embedded systems

marcH — Mon, 08 Sep 2025 07:35:48 +0000

That's not what the article seems to say. When 32bits goes entirely away, patches to "scratch your own 32 bit product" can go to /dev/null

Official video is out now

arnd — Sat, 06 Sep 2025 15:05:51 +0000

https://www.youtube.com/watch?v=QiOMiyGCoTw

Not all types are words / pointers

pizza — Fri, 05 Sep 2025 16:52:19 +0000

> * computation where _base_ data types and 32bit registers are sufficient

It's worth noting that for Arm and x86, the 64-bit instruction sets more than doubled the number of general-purpose registers available to software, and that _usually_ more than offsets the performance hit from the increased pointer size.

Not all types are words / pointers

dave4444 — Fri, 05 Sep 2025 13:40:28 +0000

There is savings to be had, but not 50%. It depends on if the application has pointer-heavy data structures or not. 32bit userspace can be a life saver for memory constrained 64bit CPUs though, CONFIG_COMPAT is well worth it.
Good for:
* pointer heavy data structures
* computation where _base_ data types and 32bit registers are sufficient
Bad for:
* older compilers/toolchains assume some instrucitons are not available and cannot optimize with them
* heavy use of int64 or double datatypes as those require multiple instructions/registers

RAM usage will be reduced, but compiled code is bigger and performance can decrease. All a tradeoff

64-bit big-endian

nowster — Fri, 05 Sep 2025 11:22:42 +0000

I could have sworn I had some 64-bit big-endian MIPS patches accepted into the kernel about ten years ago...

Why "how soon can we remove X" instead of "how long can we have X"?

urjaman — Thu, 04 Sep 2025 22:48:27 +0000

My most sincerest Thank Yous regarding support for this device do go to:

- Alyssa Rozensweig, for the panfrost GPU driver (panfrost has had many other contributors too, but she in particular is who to thank for the T760 support existing at all, and I've thanked her in $ too back when she had a ... i forgot the name for that open source patreon clone.)
- various folks on IRC (#linux-rockchip) who have translated my bisections and problem reports into the kernel development workflow (that my mind has serious trouble with).

Why "how soon can we remove X" instead of "how long can we have X"?

hmh — Thu, 04 Sep 2025 11:22:57 +0000

Well, IMHO lots of "whiners" *is* a decent metric for the importance of the continued support for the device in the kernel (and userspace, etc): it actually means people who use said devices to run Linux and keep it up-to-date, and who *care* about it.

"Chipset not-yet-in-EOL" and "units sold" metrics often just mean "stock vendor firmware stuck on a kernel from the past decade + landfill"...

M68k and SuperH are MMU ports!

DrMcCoy — Thu, 04 Sep 2025 08:28:46 +0000

Huh, interesting. Okay, I didn't expect that. :)

M68k and SuperH are MMU ports!

glaubitz — Thu, 04 Sep 2025 08:20:51 +0000

> They're not running Linux on these systems, though, are they?

Some people do, yes. We're building Debian for m68k and sh4 and there is also T2DE Linux for both.

For sh2, there is the J2 Linux port which runs on a fully open source CPU.

M68k and SuperH are MMU ports!

hrw — Thu, 04 Sep 2025 08:17:22 +0000

M68k cores done in FPGA (or emulated like in Pistorm) often do not have MMU.

Big-endian RISC-V

maskray — Thu, 04 Sep 2025 06:36:02 +0000

ELF's design emphasizes natural size and alignment guidelines for its control structures. This principle, outlined in _Proceedings of the Summer 1990 USENIX Conference, ELF: An Object File to Mitigate Mischievous Misoneism_ , promotes ease of random access for structures like program headers, section headers, and symbols.

> All data structures that the object file format defines follow the "natural" size and alignment guidelines for the relevant class. If necessary, data structures contain explicit padding to ensure 4-byte alignment for 4-byte objects, to force structure sizes to a multiple of four, etc. Data also have suitable alignment from the beginning of the file. Thus, for example, a structure containing an Elf32_Addr member will be aligned on a 4-byte boundary within the file. Other classes would have appropriately scaled definitions. To illustrate, the 64-bit class would define Elf64 Addr as an 8-byte object, aligned on an 8-byte boundary. Following the strictest alignment for each object allows the format to work on any machine in a class. That is, all ELF structures on all 32-bit machines have congruent templates. For portability, ELF uses neither bit-fields nor floating-point values, because their representations vary, even among pro- cessors with the same byte order. Of course the programs in an ELF file may use these types, but the format itself does not.

This consideration made sense in 1990 but now seems less relevant given the overwhelming prevalence of little-endian architectures.

Now big-endian support manifests either in code duplication (separate template instantiation) or runtime overhead.

```cpp
template void elf::doIcf<ELF32LE>(Ctx &);
template void elf::doIcf<ELF32BE>(Ctx &);
template void elf::doIcf<ELF64LE>(Ctx &);
template void elf::doIcf<ELF64BE>(Ctx &);
```

Today, lld's RISC-V support assumes little-endian. If we ever need to add big-endian support, we would either introduce template instantiation and make the executable larger, or make read/write calls slower for little-endian users.

To maintain confidence in refactoring, all new code requires testing. For big-endian we need to duplicate tests. Feature developers or reviewers would have to think whether an issue would work on big-endian or accept the imperfection.

Big-endian RISC-V

excors — Wed, 03 Sep 2025 20:51:29 +0000

32-bit MOVBE decodes to 2-3 uops on Intel desktop cores [1], so I'm not sure it's any better than MOV+BSWAP. It originated on Atom where it's 1 uop (so it did have a performance benefit there, presumably with some dedicated silicon), and I guess its spread to desktop cores is just for software compatibility and not performance.

[1] https://uops.info/html-instr/MOVBE_R32_M32.html / https://uops.info/html-instr/MOVBE_M32_R32.html

MIPS ?

hailfinger — Wed, 03 Sep 2025 20:23:10 +0000

I really appreciate the excellent overview you gave in that presentation. It definitely helps to have such an overview, especially from a regulatory perspective, i.e. are there still any products to be introduced in the market based on a certain platform?

Big-endian RISC-V

jrtc27 — Wed, 03 Sep 2025 20:18:14 +0000

RISC-V has REV8 to byte-swap a whole register, and if you want to swap less than a machine word you then have to right-shift.

But I imagine that even load+reverse as two instructions on AArch64 makes some of the big-endian folks unhappy still and they really don't want it to have any more overhead than a normal load.

Good to know x86 has MOVBE, and that my general principle of "if you can think of a sensible instruction, x86 and/or PowerPC has probably already done it" holds even more strongly in this case :)

Big-endian RISC-V

farnz — Wed, 03 Sep 2025 08:16:01 +0000

x86-64 has MOVBE which byte-swaps on loads.

AArch64 takes the other practical approach; it has REV, REV16, and REV32 instructions to accelerate byte-swapping after the load or before the store.

Embedded systems

nhippi — Wed, 03 Sep 2025 04:27:23 +0000

Despite the large success, Linux remains very much a "scratch your own itch" system. Support for 32bit ARM systems can remain as long your company and your SoC vendor support the effort...

M68k and SuperH are MMU ports!

azz — Tue, 02 Sep 2025 23:16:37 +0000

Or, for m68k, to FreeMINT, which runs on a surprising variety of systems now thanks to EmuTOS, and provides quite a decent Unix-ish environment that's better suited to machines of that vintage.

M68k and SuperH are MMU ports!

neggles — Tue, 02 Sep 2025 22:49:48 +0000

There's still a (small) community of users running Debian on the Dreamcast - bootable live CDs are still generated regularly :)

Big-endian RISC-V

jrtc27 — Tue, 02 Sep 2025 21:20:06 +0000

> I think this is a developer-centric perspective rather than a user-centric perspective. If there are legitimate use cases such as building open-source networking hardware based on RISC-V, then it should be legitimate to add big-endian support if someone is willing to maintain it.

But that's my point; you don't need all your normal system data to be big-endian there, all you need is for your *network packets* to be big-endian. I remain unconvinced that it would not be better to accelerate a traditionally little-endian architecture for networking by adding dedicated load/store-as-big-endian (i.e., byte swap to/from the cache) instructions on top of an otherwise little-endian system. That way there is no new ABI, no new incompatible ISA, nothing for developers to do except for networking software developers to make sure their code is written to take advantage of such instructions if available, but in reality you'd mostly expect a compiler to be able to fuse things (and maybe you'd add some special annotations on fields so they'd automatically be byte-swapped for you). PowerPC has just that in the form of l[hwd]brx - see https://godbolt.org/z/MvYz9sabG - and I can't help but feel this approach is being overlooked.

Industrial computers

andy_shev — Tue, 02 Sep 2025 18:39:07 +0000

> A lot of the embedded systems I mention in my talk are sold for long-term industrial applications, which is why they are still around, and will likely remain that way for the foreseeable future. Heeh, the article doesn't mention that and unfortunately I was not able to attend the conference. But this is good to know!

Why "how soon can we remove X" instead of "how long can we have X"?

wtarreau — Tue, 02 Sep 2025 16:18:05 +0000

Among the criteria for prolongating support, such as "boards are no longer sold", there could be "lots of whiners among users" due to this or that cheap device having been quite popular in its time :-)

Industrial computers

wtarreau — Tue, 02 Sep 2025 16:14:04 +0000

> That said, even if you do recompile the old sources with modern libc and -D_TIME_BITS=64, you can still be bitten by binary representations (network protocols, file formats, etc) that directly embed a 32-bit time_t.

Absolutely! And even harder to spot are the ones using 64-bit on a 64-bit platform but where the value transits through a 32-bit storage at one point in the chain (nastiest ones possibly being ASCII representation of the date in seconds, that some intermediate processing can easily store as signed 32-bit int). I'm pretty sure we'll see some funny issues, like dates jumping instantly to 0xffffffff or 0 because dumped as too large a number for some atoi() or even where only the first digits are parsed and the parsing stops at the first digit that causes the result to overflow, resulting in a time that advances 10 times slower. There are so many possibilities...

Big-endian RISC-V

arnd — Tue, 02 Sep 2025 16:10:57 +0000

SystemReady only applies to 64-bit Arm CPUs, and usually only on the beefier side.

Realtek's other product lines like the rtl819x wifi line or the STB/NAS rtd1xxx chips already migrated from big-endian mips32 lexra to little-endian mips32 r24k/r34k/r74k, then little-endian arm32 and now little-endian arm64, so I would expect them to do a similar progression here, possibly skipping one or two steps.

MIPS ?

wtarreau — Tue, 02 Sep 2025 16:08:36 +0000

> The ath79 family is on the second chart linked in the article, along with 7 other mips32

Ah indeed, sorry Arnd! I didn't notice them because the page was talking about Arm and most of the first ones were apparently Arm. I'm even seeing the ralink one.

Thanks for all the details BTW, these complete the table fairly well ;-)

MIPS ?

wtarreau — Tue, 02 Sep 2025 16:04:58 +0000

> On 64-bit big-endian though, the high bytes are in the first bytes in memory (...)

Yes definitely, that's the principle of endianness. Similarly when you read an in as a short you can get the wrong one, and so on. It's particularly common when dealing with port numbers for example.

For the 64-BE I'm using an old UltraSparc, it does the job pretty well and cannot stand unaligned accesses either. It's just used much less often as being more annoying to boot than a good old GL-iNet router that fits in your hand!

Industrial computers

arnd — Tue, 02 Sep 2025 15:51:26 +0000

A lot of the embedded systems I mention in my talk are sold for long-term industrial applications, which is why they are still around, and will likely remain that way for the foreseeable future.

The specific processors that I mentioned that may be removed (Intel strongarm/armv4, omap2/armv6, imx31/armv6 are no longer used in any industrial machines as far as I can tell, only in early handhelds, and they do cause problems for maintainability.

They are easy to confuse with similar industrial products though: moxart (armv4), at91rm9200 (armv4t), ep93xx (armv4t), ixp4xx/pxa (armv5), imx35 (armv6k), omap3/am3 (armv7). These all have relatively sane CPUs and DT support, so they are easy enough to maintain for many more years.

Importantly, I don't expect we'll even consider dropping armv4 (fa926) and armv4t (arm720t/arm920t) CPU support as long as we support armv5 (arm926e/pj1/xscale) based SoCs like the recently added Microchip SAM9X7.