Committing to Rust for kernel code

Posted Nov 23, 2023 14:01 UTC (Thu) by wtarreau (subscriber, #51152)
In reply to: Committing to Rust for kernel code by pizza
Parent article: Committing to Rust for kernel code

> I'll be surprised if it takes even a year, probably starting with Fedora wanting to run out of the box on modern Apple hardware. (That's going to be a fun change proposal discussion!) Meanwhile the next LTS/EL cycle is all but guaranteed to require Rust.
> As I said, "Rust is optional" makes no logical sense, giving you the worst of both worlds. Either commit to it as a core feature, or drop it entirely.

In a world where specs and compilers are distinct and evolve at their own rhythm, it would be true. But with a fast moving target which evolves to address the limitations making its use hard to impossible in the kernel for various purposes, and forcing periodic major upgrades, it will quickly become a huge mess. Gcc that didn't evolve that fast has already been quite a mess. And it did change only every few years. I was part of those who had to work on making late kernel 2.4 build with gcc-3.4 because that's what users had on their distros... In the end we only addressed two archs and the most visible stuff IIRC.

I can't imagine what it will look like in just one year with the current pace. Users will be forced to perform major updates from 6.6 to 7.1 just because "ah that old driver you're using, no, we're not maintaining it anymore, it required and old version of Rust that was not convenient for us, why don't you upgrade your LTS instead?". So that would basically mean no more long term maintenance and even more breakage in field. Sure, for plenty of use cases, nobody cares, machines are short-lived, deployed by automated scripts, and totally untuned. But for other use cases where it takes time to validate a version and adapt to it, it's another story.

Another thing is to observe how long rarely used drivers will be maintained. With a language that constantly evolves you can have change of behaviors or guarantees over time, possibly with nobody touching the driver for a while to adapt to the new version as long as it builds fine. Testing driver for hardware is very hard so that doesn't happen often. And possibly that some drivers will not build anymore after a few toolchain upgrades, and lacking a maintainer they will simply be dropped from the tree.

Time will tell, anyway, that train has already started.

Committing to Rust for kernel code

Posted Nov 23, 2023 18:29 UTC (Thu) by mathstuf (subscriber, #69389) [Link] (1 responses)

> Users will be forced to perform major updates from 6.6 to 7.1 just because "ah that old driver you're using, no, we're not maintaining it anymore, it required and old version of Rust that was not convenient for us, why don't you upgrade your LTS instead?".

Who is offering LTS kernels but not supporting the drivers they ship with it? IIUC, the kernel community isn't going to say "hey, you want to maintain this driver but we don't want you to, so we're ripping it out" is it?

> But for other use cases where it takes time to validate a version and adapt to it, it's another story.

Again, why would maintenance on the stable branch of the driver not be a suitable solution here? Presumably with the attitude the developers have in your scenario, they're not backporting anything anyways and not worried about conflicts.

Committing to Rust for kernel code

Posted Nov 24, 2023 8:42 UTC (Fri) by wtarreau (subscriber, #51152) [Link]

I'm speaking about implications of a fast-moving toolchain. When a toolchain moves fast the code can diverge quickly, to reach a point where backports are extremely complicated because sometimes they rely on a lot of new infrastructure. We've seen issues in the past where backporting fixes was a real mess. I'm thinking about the IRET bug for example, which required significant adaptations to the old code, backporting some infrastructure stuff while trying hard not to break anything. We could estimate ourselves lucky that the asm language did not evolve over all these years and that the infrastructure parts could be backported without other particular dependencies. But when you don't have all the underlying infrastructure available in older releases because it came with newer versions of the language, it's not the same game anymore. I was definitely not speaking about developers being lazy, just difficulties caused by dependencies on an updated version of a toolchain. That's not something we're used to with gcc, in the worst case it just requires less clean code.