Rust For Linux Kernel Patches Revised With Upgraded Rust Toolchain, Build Improvements

[ferry]

Me too.



I agree that none of our ministries know how to make good decisions, but that doesn't take away the fact that Python *is* used in a critical environment (Dutch government). Whether that's a good thing or not is a different subject.

That is the same ministry that lost their minister after it took them years to find the text of a settlement they had reached with a notorious criminal. Eventually they found it in an "aged financial computer system". Probably written in python2.7 :-)

[khanich]

Evidence #2: Random "big companies using Rust" articles, for example: https://serokell.io/blog/rust-companies
Almost all of these are huge companies that use dozens of languages internally, and they happen to have a few (at most) low-impact projects in Rust. Rust is not a top 10 language at any of these places.

Well, Discord's "read message" service (or whatever it's called) is written in Rust and they are quite happy with it.
I wouldn't consider that service "low-impact".

[Emmanuel Deloget]

That's probably another reason why the Rust kernel work focuses on device drivers right now. You don't need a device driver for your gaming mouse / whatever random hardware when working with an experimental or educational processor.

Yet one of the proposed driver is a GPIO extender (the PL061 from 20 years ago, which is normally found as an IP on ARM processors), and this is far worse: this is typically the kind of devices you'll find on new boards (with possibly experimental processors). Of course, I do not speak about this exact driver (the set of users of well known) but someday, someone will replace an important driver that will no longer be universally compilable - because why would the kernel community maintain both a C and a Rust driver?

I've spent a large part of the last 15 years firghting against manufacturers to make them upstream their drivers. It's now common place for new devices in the embedded world and in the server world. Whenever we build a new board we often already have an existing upstreamed linux driver for all the devices we select (with a few exceptions). I am concerned that a future me - or a future other system builder - will now have to make sure that there exists an upstreamed linux driver that he can compile to his architecture.

I understand that Rust of full of important features, some of them which cannot be implemented in a C compiler ; I understand that Rust is effectively a promising/good system-oriented language. But its not as portable as C and will probably never be (I mean: all archs are tier-1 archs ; tier-3 is not really useful: it's basically "yeah, you can try it, wait a sec I'm bringing some popcorn - this should be fun to watch..."). As a consequence, I'm not sure that moving Rust in the kernel - even if the goal is only to propose Rust-written drivers - is a good thing.

[ssokolow]

But its not as portable as C and will probably never be (I mean: all archs are tier-1 archs ; tier-3 is not really useful: it's basically "yeah, you can try it, wait a sec I'm bringing some popcorn - this should be fun to watch...").

I think that's a bit of a mischaracterization for three reasons:

1. There are efforts in progress to bring a Rust frontend to GCC (Two, in fact. One to connect the existing Rust frontend to it for up-to-date support through libgccjit's equivalent to how LLVM provides a stable API for non-JIT compilation and one to write a fresh one in C++ so it can be accepted into the GCC upstream, even if it may lag behind the reference implementation's features on occasion.)
2. We're already starting to see efforts from the other side to remedy that. For example, on the microcontroller side of things, with Espressif having developed an Xtensa ISA fork of LLVM that they're working toward getting upstreamed, and they've hired the guy who put together an ESP32 support package to work on providing first-class Rust support for their chips.
3. Most importantly, as far as "mischaracterization" goes, how many platforms have C support through an under-maintained GCC fork that's equivalent to Tier 3 in Rust in that you're only guaranteed support for the platform if you stick to a certain outdated version of the compiler?