There’s growing momentum behind an effort to make programming language Rust a second language to C for the Linux kernel. Google is backing a project led by developer Miguel Ojeda that would see Rust being used to write elements of the Linux kernel, which now underpins some of the most critical pieces of the internet’s infrastructure today. Google argues that Rust should help reduce memory errors that lead to security vulnerabilities, which make up the bulk of flaws that tech firms and open-source projects fix in each update. The goal is not to write all 30 million lines of C code again in Rust, but to write new code in Rust instead. SEE: Hiring Kit: Python developer (TechRepublic Premium) However, despite some potential benefits, it’s still not clear if the push to make Rust a second language for kernel development will succeed. At the very least, Rust for Linux must be viewed as a long-term project and is almost certain not to get mainlined into the Linux kernel in 5.14 – the version currently under development and due out as stable around the third quarter of 2021. “The project is not finished, but we are ready to get mainlined if high-level maintainers accept the current changes and prefer that we work inside the kernel,” Ojeda tells ZDNet. “Most of the work is still ahead of us.” As a result of this growing popularity, the idea of Rust in the kernel has gained support from some big tech companies. But despite some potential benefits, fans of Rust can’t simply make it a programming language for the Linux kernel on their own. It needs approval from Linus Torvalds and the high-level maintainers who guide the development of the kernel. And Torvalds hasn’t indicated whether he would approve the pull request (PR) to merge the latest Rust for Linux patches into the main Linux kernel. Ojeda posted a first request for comment (RFC) to the Linux kernel mailing list in April and followed up with a set of proposed patches in early July that he and his peers hoped would be included in the Linux kernel. Ojeda’s first RFC included examples of Rust drivers, but Torvalds’ response to the Linux drivers was not positive: he said that run-time failure panic – a type of error – is a “fundamental issue”. Torvalds’ comment highlighted the long road ahead for the Rust for Linux project. As ZDNet’s Steven J. Vaughan-Nichols reported in March, Torvalds is in the ‘wait and see’ camp for bringing Rust to the Linux kernel: he’s neither for or against Rust, but is open to seeing if its promised benefits actually pan out. “I think it’s driven by people who are very excited about Rust, and I want to see how it actually then ends up working in practice,” Torvalds told ZDNet, adding that drivers seem to be the most obvious target for Rust. Ojeda acknowledges Torvalds’ concerns about panics, but also says the team of developers attempting to bring Rust to Linux are addressing the issues. He says that removing unnecessary panics is a key concern amongst the Linux kernel community, but believes that it is “mostly a technical obstacle and has been solved.” “The other one is getting kernel modules written as proofs of concept,” says Ojeda. “The Rust Binder kernel module is working and the preliminary performance results we have in a trivial latency benchmark are better than the C version, which is very encouraging; although we are still in the process of improving the code and cleaning things up. We are also working on writing modules that drive actual hardware and coming up with ways to improve the ergonomics around that.” But the bigger hurdle, says Ojeda, is getting Linux kernel contributors, who’ve been coding in C for decades, to learn Rust and its concepts. “In my view, the bigger obstacle comes from teachability. Rust is more complex than C,” he says. That’s not a small issue either, given the hundreds of patches and changes that arrive in each new version of the kernel. Someone has to write them – and developers could now feel they need to learn Rust when they’re already operating on a tight schedule. It should be noted that the project isn’t forcing Linux maintainers to use Rust but rather providing an option to write new subsystem code in Rust. This will help them maintain and write patches themselves, says Ojeda. SEE: Computer science courses in 2021: A comprehensive overview Some of the concepts in Rust are foreign to other languages, such as the ‘borrow checker’ that developers often fight with when trying to understand when code doesn’t compile as expected; another alien concept is Rust’s safe/unsafe split. “Kernel developers are very smart, but also very busy. It is not easy to get everyone involved and explain why we think introducing a second language is worth the complexity cost,” says Ojeda. All of this means the Rust for Linux project appears to have some way to go yet before its patches are merged. Following the new patches, Linux stable kernel maintainer Greg Kroah-Hartman asked the project for a “concrete” Linux driver written in Rust. Like Torvalds, he believed kernel drivers make sense because they’re “the ’end leafs’ of the tree of dependencies in the kernel source.” And if the Rust for Linux packages are rejected, the exercise of thinking about a kernel with fewer memory bugs is an end in itself. “Even if the project got a hard no – that there is no chance at all the project will make it now or in the future – the project would not have been wasted time,” says Ojeda. “The exercise of adding a second language to the kernel is an interesting one that has generated quite a lot of discussion. Even if it were not Rust, it is good to have all that experience if another language wants to attempt it. “Most importantly, I think having raised awareness on the memory-safety guarantees that using a new approach can bring is already key. In my opinion, if we are to have any second language in the kernel, it should be one that significantly improves the state of affairs in that regard.”
