And yet, the Linux kernel's Rust code uses unstable features only available on a nightly compiler. Not optimal for ease of compilation and building old versions of the Kernel. (You need a specific version of the nightly compiler to build a specific version of the Kernel)
Can you please share more details about this?
Rust in the kernel is no longer experimental
201–210 of 853 posts
Re: Rust in the kernel is no longer experimental
#202Rust in the kernel feels like a red herring. For fault tolerance and security, wouldn’t it be a superior solution to migrate Linux to a microkernel architecture? That way, drivers and various other components could be isolated in sandboxes.
I am not a system programmer but, from my understanding, Torvalds has expressed strong opinions about microkernels over a long period of time. The concept looks cleaner on paper but the complexity simply outweighs all the potential benefits. The debate, from what I have followed, expressed similar themes as monolithic vs microservices in the wider software development arena.
I'm not a kernel developer myself, but I’m aware of the Tanenbaum/Torvalds debates in the early 90’s. My understanding is the primary reason Linus gave Tanenbaum for the monolithic design was performance, but I would think in 2025 this isn’t so relevant anymore.
And thanks for attempting to answer my question without snark or down voting. Usually HN is much better for discussion than this.
Re: Rust in the kernel is no longer experimental
#203Does the removal of “experimental” now mean that all maintainers are now obligated to not break Rust code?
No maintainer is obligated to not break any part of Linux other than the user space API, there are no stable in-kernel APIs
Re: Rust in the kernel is no longer experimental
#204Earlier quoted context omitted.
C currently remains the language of system ABIs, and there remains functionality that C can express that Rust cannot (principally bitfields). Furthermore, in terms of extensions to the language to support more obtuse architecture, Rust has made a couple of decisions that make it hard for some of those architectures to be supported well. For example, Rust has decided that the array index type, the object size type, an…
Also you can't do self-referential strutcs. Double-linked lists are also pain to implement, and they're are heavily used in kernel.
[flagged]
Re: Rust in the kernel is no longer experimental
#205Earlier quoted context omitted.
Every system under the Sun has a C compiler. This isn't remotely true for Rust. Rust is more modern than C, but has it's own issues, among others very slow compilation times. My guess is that C will be around long after people will have moved on from Rust to another newfangled alternative.
There is a set of languages which are essentially required to be available on any viable system. At present, these are probably C, C++, Perl, Python, Java, and Bash (with a degree of asterisks on the last two). Rust I don't think has made it through that door yet, but on current trends, it's at the threshold and will almost certainly step through. Leaving this set of mandatory languages is difficult (I think Fortran,…
> There is a set of languages which are essentially required to be available on any viable system. At present, these are probably C, C++, Perl, Python, Java, and Bash
Java, really? I don’t think Java has been essential for a long time.
Is Perl still critical?
Re: Rust in the kernel is no longer experimental
#206And yet, the Linux kernel's Rust code uses unstable features only available on a nightly compiler. Not optimal for ease of compilation and building old versions of the Kernel. (You need a specific version of the nightly compiler to build a specific version of the Kernel)
luckily downloading a specific nightly version is only a single rustup command
Re: Rust in the kernel is no longer experimental
#207Earlier quoted context omitted.
There are certain styles of programming and data structure implementations that end up requiring you to fight Rust at almost every step. Things like intrusive data structures, pointer manipulation and so on. Famously there is an entire book online on how to write a performant linked list in idiomatic Rust - something that is considered straightforward in C. For these cases you could always use Zig instead of C
what is an intrusive data structure?
A data structure that requires you to change the data to use it.
Like a linked list that forces you to add a next pointer to the record you want to store in it.
Re: Rust in the kernel is no longer experimental
#208Does the removal of “experimental” now mean that all maintainers are now obligated to not break Rust code?
No maintainer is obligated to not break any part of Linux other than the user space API, there are no stable in-kernel APIs
What they mean is that the Linux kernel has a long-standing policy to keep the whole kernel compilable on every commit, so any commit that changes an internal API must also fix up _all_ the places where that internal API is used.
While Rust in the kernel was experimental, this rule was relaxed somewhat to avoid introducing a barrier for programmers who didn't know Rust, so their work could proceed unimpeded while the experiment ran. In other words, the Rust code was allowed to be temporarily broken while the Rust maintainers fixed up uses of APIs that were changed in C code.
Re: Rust in the kernel is no longer experimental
#209really? I recently read that "A 100% Rust kernel is now upstream in Linux 7.4"
Re: Rust in the kernel is no longer experimental
#210Earlier quoted context omitted.
Also you can't do self-referential strutcs. Double-linked lists are also pain to implement, and they're are heavily used in kernel.
[flagged]
Don’t spread FUD, you can check some example code yourself.
https://git.kernel.org/pub/scm/linux/kernel/git/a.hindborg/l...