News: 0001475168

  ARM Give a man a fire and he's warm for a day, but set fire to him and he's warm for the rest of his life (Terry Pratchett, Jingo)

The Linux Kernel Matures To Having A Minimum Rust Toolchain Version

([Programming] 45 Minutes Ago Multiple Rust Versions)


Nearly every Linux kernel cycle has bought patches to bump the version of the Rust language targeted by the kernel as it worked toward having a suitable minimum version. With the latest Linux kernel patches, it looks like we may be finally approaching the point where a safe minimum version can be specified and for the Linux kernel to in turn allow supporting multiple different versions of the Rust compiler.

Lead developer of the Rust for Linux effort Miguel Ojeda sent out a set of patches on Monday night for opening up the Rust kernel code for targeting multiple versions of the "rustc" compiler. Miguel explained on the mailing list:

"It is time to start supporting several Rust toolchain versions and thus establish a minimum Rust compiler and `bindgen` version.

For the Rust compiler, we will start with a window of two stable releases, and widen it over time. This series keeps the minimum where it is (1.78.0), but adds support for the recently released 1.79.0.

This should already be enough for kernel developers in distributions that provide recent Rust compiler versions routinely, such as Arch Linux, Debian Unstable (outside the freeze period), Fedora Linux, Gentoo Linux (especially the testing channel), Nix (unstable) and openSUSE Tumbleweed. A documentation adds the instructions for each of them.

In addition, Rust for Linux is now being built-tested in Rust's pre-merge CI. That is, every change that is attempting to land into the Rust compiler is tested against the kernel, and it is merged only if it passes -- thanks to the Rust project for that!

Thus, with the pre-merge CI in place, both projects hope to avoid unintentional changes to Rust that break the kernel. This means that, in general, apart from intentional changes on their side (that we will need to workaround conditionally on our side), the upcoming Rust compiler versions should generally work.

For instance, currently, the beta (1.80.0) and nightly (1.81.0) branches work as well."

So given the upstream CI testing and the evolution of the Rust for Linux support across the past number of kernel cycles and upstream Rust versions, it looks like a safe minimum version is upon us for declaring Linux kernel support. The tentative 13 patches for establishing the support for handling multiple Rust toolchain versions is now out for discussion on the [1]rust-for-linux mailing list .

We'll see if this gets buttoned up in time for Linux 6.11 or is drawn out to a later kernel cycle. Having a defined minimum version and the overall maturing state of the Rust for Linux kernel ecosystem will hopefully lead to more useful Rust-based drivers and other Rust kernel code coming into development with no longer having to cater to a moving target.



[1] https://lore.kernel.org/rust-for-linux/20240701183625.665574-1-ojeda@kernel.org/



ahrs

Severe Acronym Shortage Cripples Computer Industry

SILICON VALLEY, CALIFORNIA (SVC) -- According to a recent study by the
Blartner Group, 99.5% of all possible five letter combinations have
already been appropriated for computer industry acronyms. The impending
shortage of 5LC's is casting a dark shadow over the industry, which relies
heavily on short, easy-to-remember acronyms for everything.

"Acronym namespace collisions (ANCs) are increasing at a fantastic rate
and threaten the very fabric of the computing world," explained one ZD
pundit. "For example, when somebody talks about XP, I don't know whether
they mean eXtreme Programming or Microsoft's eXceptionally Pathetic
operating system. We need to find a solution now or chaos will result."

Leaders of several SVC companies have floated the idea of an
"industry-wide acronym conservation protocol" (IWACP -- one of the few
5LCs not already appropriated). Explained Bob Smith, CTO of IBM, "If
companies would voluntarily limit the creation of new acronyms while
recycling outdated names, we could reduce much of the pollution within the
acronym namespace ourselves. The last thing we want is for Congress to get
involved and try to impose a solution for this SAS (Severe Acronym
Shortage) that would likely only create many new acronyms in the process."