Hacker News Reader

Comment by chomp | Hacker News Reader

Rust doesn't support the same amount of architectures C and Linux do, hopefully either Rust learns to support more architectures, or this stays confined to just driver code because I'd hate to see Linux disappear from some of the more esoteric architectures.

View on HN

> Another point is taking on drivers first for "any initial trials to drivers is simply the architecture side," said Torvalds. "Lots of drivers are only relevant on a couple of target architectures, so the whole issue with Rust code not being supported on some architectures is less of an issue."

Or maybe this would inspire people to expand LLVM support? There's nothing fundamental that prevents Rust from running on those architectures (as far as I know)

I don't believe there is anything fundamentally preventing any language from running on any architecture other than "we haven't gotten around to it yet". Can't you emulate any Turing machine inside of any other Turing machine? I'd guess you could run the latest version of Python on anything more advanced than a abacus if you had a couple of lifetimes to waste on the project.

My point is that a) half of the work doesn't have to happen because of LLVM's back-/front-end split, and b) if these are architectures that people care about keeping around and investing in, the benefits of adding LLVM support will go beyond just Rust

Linus is very proud of Linux running on anything, from toasters to HPC, so I think it's safe to assume less common architectures aren't going away.

It depends entirely on whether there are still developers interested in maintaining support for those architectures. It seems pretty safe to assume that Torvalds isn't going to be in favour of "we drop anything without a rust backend tomorrow"; but on the other hand 8 archs were dropped in 2018 -- https://lwn.net/Articles/749292/ -- essentially for lack of any active interest in them. It's possible that eventually "set of archs with a rust backend" and "set of archs which people care about enough to keep alive in the kernel" converge to the same set. It's even possible that one day "does this even have a rust backend?" becomes a marker of "is this thing really of use to anybody" in the same way that in 2018 "does this thing have support in upstream gcc" was a marker for "maybe we can drop this". That would be years from now, if ever, though, IMHO.

Linux removes platform support from time to time, like any project. IA64 was a recent, notable example.

That being said, it is true that Rust doesn't yet support all the platforms that are important to the kernel. That's one of the reasons this is starting with drivers, and is one of the reasons why some folks are pursuing a Rust frontend for gcc.

Plenty of them have already gone away. If they don't have people maintaining them, they get dropped over time.

I thought that was NetBSD's thing?

Indeed it was, two decades ago... Linux has taken the pole position in supported architectures now though.

Weird architectures weren't supported to begin with: https://blog.yossarian.net/2021/02/28/Weird-architectures-we...

If you're still running a system with an arcane ISA, support it yourself. 99% of the people running modern Linux are interested in three CPU architectures (four or five once RISC-V gains traction), all of them supported by Rust. Supporting old or obscure ISAs is not a priority at this point compared to bringing kernel memory safety into the 21st century, which Rust helps a lot with.

While I think I agree with this article, that isn't the case here. That article is talking about taking C code that happens to be portable to an obscure architecture, but never officially supported it, then complaining when the never-official support breaks for some reason. We're talking here about the Linux kernel, which (by necessity) was explicitly ported to every architecture it works on, so any lost architecture support would be an explicitly removed feature.

I think adding new targets to LLVM is an infititely easier task than writing safe C code (as long as the LLVM team is open to it)

The other avenue is adding a Rust frontend to GCC

This is false equivalency.

Rustc's lack of architecture support is purely an LLVM issue/

A far as I know, the latter supports many architectures the former does not.

It is true that Rust supports a subset of the architectures LLVM supports, but to be honest, I am not sure if "many" is the right adjective. I mean that in a literal sense, I don't have a good handle on the list. For Rust, the list is https://doc.rust-lang.org/nightly/rustc/platform-support.htm..., but I'm not sure if there's such a list for LLVM, other than looking at something like https://llvm.org/doxygen/Triple_8h_source.html and figuring it out?

We actually ran against this problem when I tried to get a rust toolchain up and running for our ARM v6 based product. I think that support has been added now, but it's a harder sell now because people wonder what other incompatibilities might be there, hidden, and waiting to bite us later.

Reply on news.ycombinator.com