The future of 32-bit support in the kernel

> I mean a standard 64-bit open source motherboard, peripherals, etc that aren’t locked down with binary blobs.

The problem here is scale. Having fully-open hardware is neat, but then you end up with something like that Blackbird PowerPC thing which costs thousands of dollars to have the performance of a PC that costs hundreds of dollars. Which means that only purists buy it, which prevents economies of scale and prices out anyone who isn't rich.

Whereas what you actually need is for people to be able to run open code on obtainium hardware. This is why Linux won and proprietary Unix lost in servers.

That might be achievable at the low end with purpose-built open hardware, because then the hardware is simple and cheap and can reach scale because it's a good buy even for people who don't care if it's open or not.

But for the mid-range and high end, what we probably need is a project to pick whichever chip is the most popular and spend the resources to reverse engineer it so we can run open code on the hardware which is already in everybody's hands. Which makes it easier to do it again, because the second time it's not reverse engineering every component of the device, it's noticing that v4 is just v3 with a minor update or the third most popular device shares 80% of its hardware with the most popular device so adding it is only 20% as much work as the first one. Which is how Linux did it on servers and desktops.

We kinda have this with IBM POWER 9. Though that chip launched 8 years ago now, so I'm hoping IBM's next chip can also avoid any proprietary blobs.

Until we have affordable photolithography machines (which would be cool!), hardware is never really going to be open.

NetBSD doesn't support any devices without an mmu.

I think people here are misunderstanding just how "weird" and hacky trying to run an OS like linux on those devices really is.

FWIW, Linux is not the only OS looking into dropping 32bit.

FreeBSD is dumping 32 bit:

https://www.osnews.com/story/138578/freebsd-15-16-to-end-sup...

OpenBSD has this quote:

>...most i386 hardware, only easy and critical security fixes are backported to i386

I tend to think that means 32bit on at least x86 days are numbered.

https://www.openbsd.org/i386.html

I think DragonflyBSD never supported 32bit

For 32bit, I guess NetBSD may eventually be the only game in town.

Just reading about this...turns out nommu Linux can use vfork(), which unlike fork() shares the parent's address space. Another drawback is that vfork's parent process gets suspended until the child exits or calls execve().

The comment you're responding to isn't talking about 32 vs 64 bit, but MMU vs no MMU.

> I also wish that the world would settle on a sane date-time format like the ISO 8601

IIRC, in most countries the native format is D-M-Y (with varying separators), but some Asian countries use Y-M-D. Since those formats are easy to distinguish, that's no problem. That's why Y-M-D is spreading in Europe for official or technical documents.

There's mainly one country which messes things up...

I don't know that 7-bit bytes were ever used. Computer word sizes have historically been multiples of 6 or 8 bits, and while I can't say as to why particular values were chosen, I would hypothesize that multiples of 6 and 8 work well for representation in octal and hexadecimal respectively. For many of these early machines, sub-word addressability wasn't really a thing, so the question of 'byte' is somewhat academic.

For the representation of text of an alphabetic language, you need to hit 6 bits if your script doesn't have case and 7 bits if it does have case. ASCII ended up encoding English into 7 bits and EBCDIC chose 8 bits (as it's based on a binary-coded decimal scheme which packs a decimal digit into 4 bits). Early machines did choose to use the unused high bit of an ASCII character stored in 8 bits as a parity bit, but most machines have instead opted to extend the character repertoire in a variety of incompatible ways, which eventually led to Unicode.

I believe that 10- and 12-bit bytes were also attested in the early days. As for "why": the tradeoffs are different when you're at the scale that any computer was at in the 70s (and 60s), and while I can't speak to the specific reasons for such a choice, I do know that nobody was worrying about scaling up to billions of memory locations, and also using particular bit combinations to signal "special" values was a lot more common in older systems, so I imagine both were at play.

Computers never used 7-bit bytes similarly to how 5-bit bytes were uncommon, but both 6-bit and 8-bit bytes were common in their respective eras.

As well as in a number of widely spread cryptographic algorithms (e.g. SHA-2), which use BE for historic reasons.

Of the two UTF-16 is much less of a problem, it's trivially[1] and losslessly convertible.

[1] Ok I admit, not trivially when it comes to unpaired surrogates, BOMs, endian detection, and probably a dozen other edge and corner cases I don't even know about. But you can offload the work to pretty well-understood and trouble-free library calls.

UTF-16 will be quite the mountain as Windows APIs and web specifications/engines default to it for historical reasons.

I have some places in some software where I assume little endian for simplicity, and I just leave in a static_assert(std::endian::native == std::endian::little) to let future me (or future someone else) know that a particular piece of code must be modified if it is ever to run on a not-little-endian machine.

"perfection"

That is a fair point! I do think though that it would make sense for maintainers to at least put out an open call to users and developers before dropping something as fundamental as 32 bit support. The reality is that not all users are going to be kernel developers, and even many developers today aren’t familiar with the workflow kernel development requires. Mailing lists, patch submission processes, and the cultural expectations around kernel work are all a pretty steep barrier to entry, even if someone does care about the removal and also happens to be a developer.

The other dynamic here is that the direction in Linux does come from the top. When you have maintainers like Arnd Bergmann saying they would "like" to remove support for hardware (like the ARM boards), that sets the tone, and other contributors will naturally follow that lead. If leadership encouraged a philosophy closer to "never break existing hardware" the same way we’ve had "never break userspace" for decades, we probably wouldn’t even be debating removing 32 bit.

I’m not saying kernel devs need to carry the weight alone, but it would be nice if the community’s baseline stance was towards preservation rather than obsolescence. :(

Applications don't get 4GB with a 32-bit address space. The practical split between application and kernel was usually 1-3 or 2-2 with 3-1 being experimental and mooted with the switch to 64-bit. Nowadays with VRAM being almost as large as as main RAM, you need the larger address space just to map a useful chunk of it in.

When you factor in memory fragmentation, you really only had a solid 0.75-1.5GB of space that could be kept continuously in use. That was starting to become a problem even when 32-bit was the only practical option. A lot of games saw a benefit to just having the larger address space, such that they ran better in 64-bit with only 4GB of RAM despite the fatter 64-bit pointers.

I wish x32 had taken off; better performance and lower memory use.

https://wiki.debian.org/X32Port

Yes and no. A problem with 8-bit and 16-bit for desktop and servers is the limited memory address space, so the compiler has to insert extra instructions to deal with things like updating the segment registers. And likewise if you need to do higher-bit math then the compiler again has to insert extra instructions. Those extra instructions clog up the pipeline, but aren't needed if your largest program's working memory set and the largest precision math you generally need fits within the ISA's bit size. Unless you are doing scientific computing or other large-memory set tasks like Blender (which dropped 32-bit support), then 32-bit really is good-enough.

I couldn't tell if your comment was a joke, but it is worth mentioning the 8-bit microcontrollers like TinyAVR still fill a niche where every joule and cent counts.

Yeah, games I'd guess is the most common case or at least one enough people would care about.

In some ways, Windows already does that too - the 32-bit syscall wrappers [switch into a 64-bit code segment](https://aktas.github.io/Heavens-Gate) so the 64-bit ntdll copy can call the 64-bit syscall.

I would guess so, but I haven't seen anyone developing that so far.

I have heard people say the only stable ABI on Linux is Win32.

> most of those games would have windows builds?

Yeah, that's a reasonable workaround, as long as it doesn't hit that OpenGL problem above (now it mostly affects DX7 era games, since they don't have Vulkan translation path). Hopefully it can be fixed.

LIME Isn’t Merely an Emulator