Rust in the Linux kernel: part 2
1–10 of 73 posts
Re: Rust in the Linux kernel: part 2
#2>The next article in this series will look at the design of the interface between the C and Rust code in the kernel, as well as the process of adding new bindings when necessary.
This is the actual useful one since so little of the kernel has Rust bindings. When I tried to implement a filesystem driver in rust I spent most of my time trying to write bindings instead of trying to write a filesystem.
Re: Rust in the Linux kernel: part 2
#3>The next article in this series will look at the design of the interface between the C and Rust code in the kernel, as well as the process of adding new bindings when necessary. This is the actual useful one since so little of the kernel has Rust bindings. When I tried to implement a filesystem driver in rust I spent most of my time trying to write bindings instead of trying to write a filesystem.
There are projects that make more sense:
https://arxiv.org/abs/2506.03876
https://github.com/asterinas/asterinas
The reasons we encounter pattern issues forcing Linux into a polyglot is not a new phenomena:
https://en.wikipedia.org/wiki/Second-system_effect
Best regards =3
Re: Rust in the Linux kernel: part 2
#4[flagged]
Re: Rust in the Linux kernel: part 2
#5[flagged]
My interest in Rust comes from getting frustrated with C's type system. Rust has such a nice type system and I really enjoy the ownership semantics around concurrency. I think that C++ written "correctly" looks a lot like Rust and libkj [1] encourages this, but it is not enforced by the language.
[1] https://github.com/capnproto/capnproto/blob/v2/kjdoc/tour.md
Re: Rust in the Linux kernel: part 2
#6[flagged]
Most of the interest I have seen is in pursuit of security.
A few sources have cited that something like 70% of vulnerabilities are rooted in memory safety issues.
A language that makes it impossible to introduce 70% of the security bugs is appealing.
Re: Rust in the Linux kernel: part 2
#7[flagged]
Rust (without use of `unsafe`) eliminates several entire classes of bugs (including bugs that comprise the majority of security related memory safety issues) while providing performance comparable to C/C++.
That is really all there is to it - it is just the better option for systems programming by almost all available metrics, and I say this as someone who has been coding C and C++ professionally for coming up on 25 years.
Re: Rust in the Linux kernel: part 2
#8[flagged]
I mean I don't mind learning it if it solves problems and is reasonably enjoyable to program in (which I find C/C++ to be) but the rebel in me doesn't want to conform to what big business/politics wants I guess. I know thats a terrible metric to use in this field.
Re: Rust in the Linux kernel: part 2
#9[flagged]
The general spike in interest from 2021 onwards (the language has been around for a while so it's not like people just found out) is due to a large hangover from crypto folks who become jobless after the bust. Super savvy in general being online and evangelism. The safety stuff is overblown (small subset of applications primarily OS and browsers) and full rewrite is not possible or advisable.
Re: Rust in the Linux kernel: part 2
#10[flagged]
The general spike in interest from 2021 onwards (the language has been around for a while so it's not like people just found out) is due to a large hangover from crypto folks who become jobless after the bust. Super savvy in general being online and evangelism. The safety stuff is overblown (small subset of applications primarily OS and browsers) and full rewrite is not possible or advisable.
This is the sort of thing I suspected without proof. It seems people do find that Rust is useful in terms of specific types of bugs but why cant pre C/C++ 11 just do the same job.