https://lwn.net/Articles/849849/ LWN.net Logo LWN .net News from the source LWN * Content + Weekly Edition + Archives + Search + Kernel + Security + Distributions + Events calendar + Unread comments + ------------------------------------------------------------- + LWN FAQ + Write for us User: [ ] Password: [ ] [Log in] | [Subscribe] | [Register] Subscribe / Log in / New account Rust support hits linux-next [Posted March 19, 2021 by corbet] Followers of the linux-next integration tree may have noticed a significant addition: initial support for writing device drivers in the Rust language. There is some documentation in Documentation/rust, while the code itself is in the rust top-level directory. Appearance in linux-next generally implies readiness for the upcoming merge window, but it is not clear if that is the case here; this code has not seen a lot of wider review yet. It is, regardless, an important step toward the ability to write drivers in a safer language. ----------------------------------------- (Log in to post comments) Rust support hits linux-next Posted Mar 19, 2021 15:17 UTC (Fri) by kragil (guest, #34373) [Link] Really interesting and awesome development. Rust could be a more productive and safer solution for a lot of driver development, but we have to wait and see. [Reply to this comment] Rust support hits linux-next Posted Mar 19, 2021 16:12 UTC (Fri) by darwi (subscriber, #131202) [ Link] There is also an example character driver at drivers/char/ rust_example.rs A lot of standard kernel abstractions and APIs are not yet "rustified" at all. Having a character driver is also not the most encouraging of examples: adding new character drivers to the kernel is really frowned upon -- real drivers need way much more functionality than just FileOperations, a Mutex, and an (incomplete) SpinLock API. Nonetheless, the merge to -next is of course a very encouraging sign. [Reply to this comment] Rust support hits linux-next Posted Mar 20, 2021 0:04 UTC (Sat) by ndesaulniers (subscriber, # 110768) [Link] I think kbuild support is more important. Those interfaces and abstractions will come over time as needed. Without build system support, you can't even try to write them. This initial patch set also attempts to put these interfaces in a single shared location in tree, so that drivers can be built in tree, and share code in tree. [Reply to this comment] Rust support hits linux-next Posted Mar 20, 2021 2:33 UTC (Sat) by willy (subscriber, #9762) [Link ] I was asked what I thought of this by one of the people working on it, and I suggested they write an NVMe driver. The spec and hardware is readily available, it's relatively high performance hardware, it's something you'd actually want to have, and it doesn't have to depend on too much of the rest of the kernel (PCI services and block layer). Maybe they're still working on it! [Reply to this comment] Rust support hits linux-next Posted Mar 20, 2021 13:16 UTC (Sat) by atnot (subscriber, #124910) [ Link] I think this is intended to be an example driver, not a proof of concept driver. So it's main purpose is intended to be as a documentation reference. Requiring people to understand NVMe is kind of unhelpful for that purpose. [Reply to this comment] Rust support hits linux-next Posted Mar 20, 2021 14:00 UTC (Sat) by willy (subscriber, #9762) [ Link] NVMe is pretty simple. The original driver was less than 2000 lines. It's only so complicated in the kernel now because some idiots decided to make the same driver support NVMoF instead of adding a separate driver for it. The advantage of writing an actual driver for hardware that really exists is that you figure out what's missing from the kernel Rust API -- interrupts, PCI, DMA, locks that need to be shared with code written in C. That kind of thing. [Reply to this comment] Rust support hits linux-next Posted Mar 19, 2021 22:02 UTC (Fri) by flussence (subscriber, #85566) [Link] Well, that's one way to fend off C++/microkernel fanatics. If I had to guess, nothing much is going to come of this for maybe 2-3 years. By then I'd expect GCC to have a Rust frontend and everything can be business as usual. [Reply to this comment] Rust support hits linux-next Posted Mar 20, 2021 14:10 UTC (Sat) by adobriyan (guest, #30858) [ Link] C++ can't be fended off. Any source-incompatible-with-C programming language is doomed to live in separate sandbox where developers are converting unimportant drivers until the steam runs out. [Reply to this comment] Rust support hits linux-next Posted Mar 20, 2021 19:06 UTC (Sat) by stevenrwalter (subscriber, # 128616) [Link] Are you saying you think there will be C++ in the kernel tree at some point? Also C++ is not source-compatible with C [Reply to this comment] Rust support hits linux-next Posted Mar 20, 2021 22:18 UTC (Sat) by adobriyan (guest, #30858) [ Link] > Are you saying you think there will be C++ in the kernel tree at some point? I can't even push trivial stuff like renaming few "this" identifiers, so no. > Also C++ is not source-compatible with C C++ is maximally source compatible with C which automatically makes it the best candidate for upgrading to a more capable programming language. Trivial sources of source incompatibility come from casts and keywords (people like plain "new" very much) but they can be scripted away. I mean Googlers who posted Rust to linux-next are surely capable of it. The most difficult sources of incompatibility don't come from C99 initialisers (which can be rearranged) but from code like this: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/... If someone knows how C++ people deal with macrology/features above, please tell me. Modules also have a _lot_ of icky macros as does tracing. I don't even want to think about it. The biggest problem so far is g++ being so eager to shift compile time initialisation to runtime. So far all oopses but one in my little Linux++ project were caused by this: empty system call table, empty paravirt ops and empty protection_map [] array. That one different oops was int/long confusion in ERR_PTR rewrite. C99 caluse shuffling is very dangerous when rebasing. It is so easy to mismerge stuff and omit or double init. Double init is tolerable because g++ complains but omission is silent. [Reply to this comment] Rust support hits linux-next Posted Mar 20, 2021 22:24 UTC (Sat) by adobriyan (guest, #30858) [ Link] The best part was min/max rewrite. I liked it so much. template constexpr T min(T a, T b, Ts... etc) { if constexpr (sizeof...(Ts) == 0) { return (a < b) ? a : b; } else { return min(min(a, b), etc...); } } [Reply to this comment] Rust support hits linux-next Posted Mar 20, 2021 22:12 UTC (Sat) by amarao (subscriber, #87073) [ Link] I see a lot of niceness there. Good error types, traits, etc. Nevertheless I feel slightly odd reading examples and pieces. It all ... not high level. I mean there is a constant flux of small things about low-level details. Rust is loved for high level feeling even when dealing with low-level details, like atomics and mutexes. I'd like to see more polished base, where all kernel grind been enveloped in a higher level abstractions. [Reply to this comment] Copyright (c) 2021, Eklektix, Inc. Comments and public postings are copyrighted by their creators. Linux is a registered trademark of Linus Torvalds