Committing to Rust for kernel code

Posted Nov 23, 2023 19:48 UTC (Thu) by pbonzini (subscriber, #60935)
In reply to: Committing to Rust for kernel code by linusw
Parent article: Committing to Rust for kernel code

Rust is trivial to learn and insanely hard to master, let's not kid ourselves. Most maintainers in the kernel could not write (and could barely read) the code for some of the bindings. See for example the workqueue bindings, https://lwn.net/Articles/932271/ (might not be the last version, the point still stands).

The way it works is to trust that the people who contributed them, or someone else, will be around to help. Fortunately the Linux APIs are relatively stable, and changes are less frequent than people think, but I think it's reasonable at least for now to have even experienced C programmers ask for help, because introducing technical debt would be worse.

Committing to Rust for kernel code

Posted Nov 24, 2023 20:02 UTC (Fri) by tlamp (subscriber, #108540) [Link] (1 responses)

IME the hardest part is writing good and rust-idiomatic bindings, but once that hard work is done (yes, often by experts) working with them can be done by non-experts too.

ps. How's QEMU's stance on rust? Our backup driver [0][1] would surely look a bit nicer with more native support.

[0]: https://git.proxmox.com/?p=proxmox-backup-qemu.git;a=summary
[1]: https://git.proxmox.com/?p=pve-qemu.git;a=blob;f=debian/p...

Committing to Rust for kernel code

Posted Nov 25, 2023 14:04 UTC (Sat) by pm215 (subscriber, #98099) [Link]

My impression is that QEMU's stance on Rust is roughly "might be interesting but unless a group of Rust experts turn up who want to do the massive amounts of work involved in demonstrating and then implementing a transition plan, it's probably not happening any time soon". Some parts that can be offloaded into separate processes that talk some defined protocol have been done in Rust, but they are all out of tree separate projects. Rust in the main QEMU binary is a much trickier thing.