Hacker News Reader

Comment by bmicraft | Hacker News Reader

Which ones would that be?

In order to figure this out I took the list of platforms supported by Rust from https://doc.rust-lang.org/nightly/rustc/platform-support.htm... and those supported by Linux from https://docs.kernel.org/arch/index.html, cleaned them up so they can be compared like for like and then put them into this python script:

  linux = { "alpha", "arc", "arm", "aarch64", "csky", "hexagon",
    "loongarch", "m68k", "microblaze", "mips", "mips64", "nios2",
    "openrisc", "parisc", "powerpc", "powerpc64", "riscv",
    "s390", "s390x", "sh", "sparc", "sparc64", "x86", "x86_64",
    "xtensa" }
  
  rust = { "arm", "aarch64", "amdcgn", "avr", "bpfeb", "bpfel",
    "csky", "hexagon", "x86", "x86_64", "loongarch", "m68k",
    "mips", "mips64", "msp430", "nvptx", "powerpc", "powerpc64",
    "riscv", "s390x", "sparc", "sparc64", "wasm32", "wasm64",
    "xtensa" }
  
  print(f"Both: {linux.intersection(rust)}")
  print(f"Linux, but not Rust: {linux.difference(rust)}")
  print(f"Rust, but not Linux: {rust.difference(linux)}")

Which yields:

Both: {'aarch64', 'xtensa', 'sparc', 'm68k', 'mips64', 'sparc64', 'csky', 'riscv', 'powerpc64', 's390x', 'x86', 'powerpc', 'loongarch', 'mips', 'hexagon', 'arm', 'x86_64'}

Linux, but not Rust: {'nios2', 'microblaze', 'arc', 'openrisc', 'parisc', 's390', 'alpha', 'sh'}

Rust, but not Linux: {'avr', 'bpfel', 'amdcgn', 'wasm32', 'msp430', 'bpfeb', 'nvptx', 'wasm64'}

Personally, I've never used a computer from the "Linux, but not Rust" list, although I have gotten close to a DEC Alpha that was on display somewhere, and I know somebody who had a Sega Dreamcast (`sh`) at some point.

some of the platforms on that list are not supported well enough to say they actually have usable rust, e.g m68k

Well, GCC 15 already ended support for the nios2 soft-core. The successor to it is Nios V which runs RISC-V. If users want us update the kernel, they'll also need to update their FPGA.

Microblaze also is a soft-core, based on RISC-V, presumably it could support actual RISC-V if anyone cared.

All others haven't received new hardware within the last 10 years, everybody using these will already be running an LTS kernel on there.

It looks like there really are no reasons not to require rust for new versions of the kernel from now on then!

Is this the same NIOS that runs on FPGA? We wrote some code for it during digital design in university, and even an a.out was terribly slow, can't imagine running a full kernel. Though that could have been the fault of the hardware or IP we were using.

You fell into the trap I predicted a few years ago when the renaming happened. Microblaze refers to the old microblaze soft core, not the new one that they named the same thing and that is based on RISCV.

It’s an interesting list from the perspective of what kind of project Linux is. Things like PA-RISC and Alpha were dead even in the 90s (thanks to the successful Itanium marketing push convincing executives not to invest in their own architectures), and SuperH was only relevant in the 90s due to the Dreamcast pushing volume. That creates an interesting dynamic where Linux as a hobbyist OS has people who want to support those architectures, but Linux as the dominant server and mobile OS doesn’t want to hold back 99.999999+% of the running kernels in the world.

There was a time when it came to 64 bit support Alpha really was the only game in town where you could buy a server without adding a sixth zero to the bill. It was AMD, not Itanium that killed Alpha.

I remember that time being before 64-bit became a requirement for most people (I worked with some computational scientists who did buy Alphas for that reason since they needed the flat memory space without remapping hacks). The Alpha was indeed great but Intel did enough of a job convincing most manufacturers that the only future was Itanium that only a few niche workstation manufacturers picked up the Alpha, and they had 64-bit competition from SPARC, MIPS, and POWER pretty quickly.

I do agree that it was AMD which really made 64-bit mainstream. There’s an interesting what-if game about how the 90s might’ve gone if Intel’s marketing had been less successful or if Rick Belluzo hadn’t bought into it since he killed PA-RISC and HPUX before moving to SGI where he killed both MIPS and Irix and gave the high-end graphics business to nVidia.

AMD, and the addition of PAE to the Pentium Pro which allowed 32-bit systems to reasonably have huge (for that time) amounts of memory

HP owned Compaq already, which had previously bought DEC, when the Alpha was killed. HP chose Itanium for their servers. They settled some patent issues with Intel partly by killing Alpha instead of a more traditional cross-licensing agreement.

AMD killed Itanium. HP was pretty far along killing Alpha all on their own.

I've certainly used parisc and alpha, though not for some years now.

You probably shouldn't include Rust's Tier 3 in this list. If you have to, at least make it separate.

There's Rust for Dreamcast (https://dreamcast.rs) via Rust's GCC backend.

https://lwn.net/Articles/1045363/

> Rust, which has been cited as a cause for concern around ensuring continuing support for old architectures, supports 14 of the kernel's 20-ish architectures, the exceptions being Alpha, Nios II, OpenRISC, PARISC, and SuperH.

> supports 14 of the kernel's 20-ish architectures

That's a lot better than I expected to be honest, I was thinking maybe Rust supported 6-7 architectures in total, but seems Rust already has pretty wide support. If you start considering all tiers, the scope of support seems enormous: https://doc.rust-lang.org/nightly/rustc/platform-support.htm...

They probably get a few for "free" from LLVM supporting them

Wasn't that a whole tent pole of LLVM?

LLVM platform support is neither sufficient (rustc needs to be taught about the platform) not technically necessary (you could write a rustc backend that targets a platform that LLVM doesn't, like modifying cranelift or once the gcc backend reaches maturity).

Its strange to me that Linux dropped Itanium two years ago but they decided to keep supporting Alpha and PA-RISC.

I do wonder how many humans beings are running the latest linux kernel on Alpha.

Itanium was mainly dropped because it was impeding work in the EFI subsystem. EFI was originally developed for Itanium before being ported to other platforms, so the EFI maintainers had to build and test their changes to shared code on Itanium. They eventually decided that this wasn't worth the effort when there was basically nobody running modern Linux on Itanium besides a few hobbyists. I imagine that alpha and hppa will get dropped in the future if they ever also create an undue maintenance burden. There's more context here if you're interested: https://lwn.net/Articles/950466/

And more specifically which ones that anyone would use a new kernel on?

Some people talk about 68k not being supported being a problem

m68k Linux is supported by Rust, even in the LLVM backend.

Rust also has an experimental GCC-based codegen backend (based on libgccjit (which isn't used as a JIT)).

So platforms that don't have either LLVM nor recent GCC are screwed.

how on earth is linux being compiled for platforms without a GCC?

additionally, I believe the GCC backend is incomplete. the `core` library is able to compile, but rust's `std` cannot be.

I don't believe Rust for Linux use std. I'm not sure how much of Rust for Linux the GCC/Rust effort(s) are able to compile, but if it was "all of it" I'm sure we'd have heard about it.

>nor recent GCC are screwed.

Not having a recent GCC and not having GCC are different things. There may be architectures that have older GCC versions, but are no longer supported for more current C specs like C11, C23, etc.

Reply on news.ycombinator.com