If you pay attention, you can see more such awesome articles
By Jonathan CorbetSeptember 19, 2022Maintainers SummitDeepL assisted translationhttps://lwn.net/Articles/908347/
The Rust for Linux project, which is a project that hopes to write kernel code using the Rust programming language in the future, has been in the works for several years, and more and more developers believe that it is time to incorporate this work into the mainline. At the Linux Kernel Maintainers Summit 2022, Miguel Ojeda updated the project on the status of the project, hoping to agree on when the merge could be completed. The answer he got was clear: there would indeed be Rust in the kernel soon.
There is no suspense in this regard; Linus Torvalds said at the start of the meeting that he plans to accept the Rust patch for the 6.1 kernel (which could be released in mid-December) unless he hears strong opposition. Ojeda said he was looking forward to the day and asked how the patches should make their way into the mainline. Torvalds says he’s reluctant to accept the patches directly, so it looks likely that Kees Cook will be needed to lead the work to upstream.
Dave Airlie says there are some MacBook driver developers who intend to use Rust to do their jobs, so it’s likely that a real Rust driver will be on the upstream soon. However, Torvalds says he wants to start with as little content as possible, just let the infrastructure go into the kernel first and let developers start using it. It should compile completely, but it should be basically limited to the “hello, world” level. He said it would be a signal to the world: “Finally landed”.
Greg Kroah-Hartman asks how to enter upstream for a Rust binding implementation for a particular subsystem. Should it go through the Rust tree or through the maintainers of the related subsystems? Ojeda replied that core Rust support should be integrated through the Rust tree, but others should be integrated by maintainers. Alexei Starovoitov worries that subsystem maintainers can’t reject Rust patches if they don’t want to use Rust in their subsystems. James Bottomley added that Rust can be a difficult language for long-term C developers to understand, and it is not appropriate to impose it on maintainers. Torvalds replied that it should be up to the maintainers to decide; There is no need for uniform rules at this time.
Paolo Bonzini says that for developers unfamiliar with the language, Rust code that implements an abstraction layer for a particular subsystem is often the hardest to read, “but it’s stupid code,” without any complicated action. Driver-level Rust code is much simpler to understand. Torvalds reiterated that for now, maintainers will be able to say they don’t want to accept Rust. But Starovoitov counters that BPF will be affected no matter how he decides; Developers need to be able to tracing Rust code to debug problems. He added that everyone will eventually need to know Rust. Torvalds replied that he expects the process to take several years.
Cook says this change will be similar to many C language changes that the kernel goes through. Discontinuing the use of variable-length arrays is a similar process, and developers are currently used to this. Torvalds says it’s actually more akin to the introduction of BPF. It’s also a new language that was originally for specific usage scenarios, but is now ubiquitous.
Ted Ts’o notes that the kernel must use unstable Rust features, which makes it difficult to determine which version of Rust should be used. Maybe a developer should announce a specific version of the compiler as the version used for kernel development? This will encourage distribution providers to package and distribute this version so that it can be more widely adopted. Thomas Gleixner said that it should be enough to provide the compiler of our choice on the kernel.org, but Torvalds replied that whenever possible, he wanted to get the compiler from the distribution provider first. Bottomley asks when Rust will become a prerequisite for kernel compilation. The answer is “when someone needs to use hardware that needs Rust”. Torvalds says that if that day comes, it means that Rust is very successful in the field of kernel development.
Gleixner asked how normative the Rust language is now; Ojeda replied that it depends on what people want to use. Rust ensures that stable features are backwards compatible, so they don’t accidentally become unusable. However, the kernel is using some unstable features; Changes to these features are likely. The work currently being done is to stabilize these functions so that the kernel can use them stably.
Efforts are underway to write a specification for Rust for safety-critical systems, which will eventually result in a standard-like document. However, Ojeda says that developers of the current GCC-based gccrs Rust compiler find some of the current documentation ambiguous. It often defines the behavior as “referring to the implementation of the rustc compiler”. This, he said, is “not a good thing” but will continue to improve.
Gleixner also asked about the tools used to generate Rust binding, especially if there are automated tools to ensure that the data structures of the Rust and C versions are matched. Ojeda says these tools do exist, but they don’t yet succeed in auto-conversion for all types. This is also solvable.
Finally, Gleixner cautioned Rust developers not to change the semantics of locking primitives in C. At present, it seems that everyone has not shown such a tendency. Ts’o added that Rust’s locking abstraction should be paired with lockdep, a locking checking tool, from the start. Chris Mason interjects that if Rust code needs lockdep, it will be another sign of the language’s success, and it’s time to “dance to celebrate victory.”
It is often said that merging Rust into the kernel code tree is still an experimental action; If it is unsuccessful, it can be deleted. Ojeda says developers working for Rust for Linux want to know how long the trial period might be. However, he did not get a practical answer from this panel discussion.
Instead, Bottomley suggests that instead of introducing Rust, it would be better to move more Rust-like functionality directly into C. Ojeda says he’s actually been working with the C Language Committee to push for these improvements, but any changes in this area will also take a long time if they are implemented. Christoph Hellwig says that unless there are plans to rewrite the entire kernel with Rust, such changes will have to be made anyway. He wasn’t very happy with the idea of using a new language to rewrite code that already worked. Maybe the sparse static analysis tool could be enhanced to allow for more checks that Rust can do, he says. Ojeda replied that the end result was like getting another Rust — but much later.
Hellwig goes on to say that some features like Rust can be gradually adopted over time. This “must be better to start with Rust”, but the kernel community now has a huge code base to manage. He said there needed to be a way to incorporate the benefits of a Rust-like language into all C code. Cook says he’s been pushing compiler developers to create a safer C language.
Ts’o noted at the end of the conference that language design itself is a time-consuming research project; Maybe we should all focus on policy in the next year. Torvalds says he would like to see maintainers run some continuous integration tests and add Rust-related tests — something that’s already underway. Laurent Pinchart says Rust developers need to be prepared for the upfront need to support the kernel community. Developers will quickly acquire some skills and should be able to start helping each other after a while. Torvalds added that Rust isn’t actually that scary; “Not Perl after all.”
When asked about documentation, Ojeda said that Rust’s developers are trying to improve some of the documentation that has already been done in the corresponding C language. For example, it would make it easy for Rust’s documentation mechanism to ensure that these examples can be tested in real time. They’re refining some rules to talk about unsafe blocks of unsafe code.
Time was running out, and Matthew Wilcox finally asked whether kernel developers should write idiomatic Rust code or “C in Rust.” Ojeda replied that the code might have been more like C in the beginning; Adopting more advanced features, such as async, may take longer. Gleixner asks how to prevent developers from using unstable features (i.e., after the kernel uses features that have become stable). The answer is to specify the compiler version to use when developing the kernel.
The full LWN article follows the CC BY-SA 4.0 license.
Long press the QR code below to follow, pay attention to LWN in-depth articles and various recent remarks from the open source community~