We Show You Reviews on the Latest Electronics, Techs, the most incredible Gadgets and inventions

Rust code in Linux kernel looks more likely as language team lead promises support • The Register

Rust language team lead Josh Triplett has promised to support its use in the Linux kernel, saying: “I’d be happy to have the Linux kernel feeding into Rust language development priorities. If building Rustic interfaces within the kernel requires some additional language features, we should see what enhancements to the language would best serve those requirements.”

The context for these remarks is a discussion on the kernel mailing list about a proposed session for the Linux Plumbers conference taking place online next month, aimed at open-source developers working on the innards of Linux, such as the kernel, core libraries and windowing systems. Google engineer Nick Desaulniers proposed the topic of Linux Kernel in-tree Rust support as part of an LLVM “micro conference”.

The topic caught the attention of several key people in the Linux community, including overseer Linus Torvalds and kernel maintainer Greg Kroah-Hartman. Torvalds has already mentioned Rust as a possible additional language for kernel development, though he went on to downplay the idea by saying it would be for things “not very central to the kernel itself” such as drivers. The kernel is primarily written in C.

Triplett said Rust should be made to “fit naturally into the kernel’s norms and standards, while also introducing some of Rust’s norms and standards where they make sense.” He said there should be “appropriate Rustic interfaces that are natural and safe to use” rather than relying on the C Foreign Function Interface (FFI).

There was also a discussion about how to introduce Rust gradually. Triplett proposed a configuration option so that “neither ‘makeallnoconfig’ nor ‘make allyesconfig’ would require Rust until we’ve had plenty of time to experiment with it.”

This is where Torvalds jumped in, saying: “No, please make it a ‘is rust available’ automatic config option. The exact same way we already do the compiler versions and check for various availability of compiler flags at config time… I _don’t_ want us to be in the situation where any new Rust support isn’t even build-tested by default… The _worst_ situation to be in is that a (small) group of people start testing their very special situation, and do bad and crazy things because ‘nobody else cares, it’s hidden.’ No, thank you.”

The attraction of Rust is that it is a modern systems-level programming language that is both easier to use and safer than C or C++. A year ago, Microsoft’s security research team posted about “why we think that Rust represents the best alternative to C and C++ currently available.”

The initial attraction is safety, said Microsoft principal cloud developer advocate Ryan Levick. “What separates Rust from C and C++ is its strong safety guarantees. Unless explicitly opted-out of through usage of the ‘unsafe’ keyword, Rust is completely memory safe,” with obvious attractions for operating systems like Windows which have suffered many memory-related bugs such as buffer overflow errors.

There is more to Rust than that, though, and Levick also referred to other features. “Many teams at Microsoft have found that Rust’s rich type system makes writing expressive programs possible,” he said.

Blockers to Rust adoption at Microsoft, Levick wrote, are “lack of first-class interoperability with C++, and interoperability with existing Microsoft tooling.”

Another potential issue for Linux with Rust is that the Rust compiler is updated frequently, raising the risk of a compiler upgrade introducing an instability. Triplett said: “Rust has hard stability guarantees when upgrading from one stable version to the next.”

Torvalds responded: “The worry is more about actual compiler bugs, not the set of exposed features… Compiler bugs are very rare, but they are so incredibly hard to debug when they happen that they end up being extra special.”

The interest in using Rust for kernel development, and its support in principle from the likes of Torvalds and Kroah-Hartman, suggest that this may well happen, though it will be introduced slowly and carefully. ®