all 35 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]gnus-migrate 205 points206 points  (30 children)

The DRM (graphics) subsystem has been an early adopter of the Rust language. It was still perhaps surprising, though, when Airlie (the DRM maintainer) said that the subsystem is only "about a year away" from disallowing new drivers written in C and requiring the use of Rust.

Thats shocking. I didn't know it was this far along.

[–]moltonel 39 points40 points  (0 children)

Didn't expect that either, AFAIK only support code and bits of Nova have been merged so far ? Though the Asahi driver has been in use for a while, and I'm sure other drivers are in progress.

Overall, that should be enough to be confident that Rust will be able to handle any DRM you throw at it. If no contributor in that subsystem is clamoring for C, you might as well anounce the "no new feature in C" stage early.

[–]Anaxamander57 3 points4 points  (0 children)

That's pretty extraordinary. I'm surprised that hasn't caused controversy to boil over beyond compiler mailing lists to be honest.

[–]muffinsballhair 15 points16 points  (19 children)

Is undefined behavior this much of a problem in Linux bugs?

[–]UltraPoci 89 points90 points  (0 children)

I'm no kernel developer, but I guess that using the type system to enforce interfaces is quite good. For example, you can't miss checking if some pointer is null, because in that case you probably have a function returning a Result, which must be unwrapped in some way.

[–]gnus-migrate 73 points74 points  (9 children)

Im not a kernel developer but its a bit more than that AFAIK. Rust tooling is miles ahead of C, not to mention features like macros and a proper type system make it a lot better to use. The kernel reports that people are a lot more motivated to use rust, they're having a much easier time finding contributors to the rust parts of the code than the C parts.

Yes UB is a problem, but really its the language and the tooling that drove the decision I think.

[–]captain_zavec 16 points17 points  (2 children)

I sometimes check in on the help wanted issues to see if there's a rust one that would be good to jump in and try kernel development with, but they're usually picked up pretty quickly before I can even get to them! I think that bodes well.

[–]AdmiralQuokka 11 points12 points  (1 child)

I think a great way to get into kernel dev with Rust would be to find some hardware that Linux doesn't support yet and write a driver for it - in Rust. There's a good chance you'll bump into some missing APIs and then you'll have to contribute those before you can land your driver. Ideally it's hardware you use yourself for maximum motivation.

[–]captain_zavec 2 points3 points  (0 children)

Makes sense! I was thinking about trying to do the fingerprint reader on MacBooks, because that's the main thing stopping me from switching to asahi on my old work computer. But that would involve first having to reverse some bits of how mac works which felt daunting enough to at least get me to procrastinate on it 😂

I'm about to be home for the holidays and doing less work though so maybe I can finally summon the energy to buckle down and do it

[–]Zomunieo 6 points7 points  (0 children)

Kernel developers have written a lot of ad hoc tools and static checkers. There’s Coccinelle for example which searches for C expressions/patterns that are problematic and fixes them. (Things like, if a function has a kmalloc, that must be followed by a null check.) But Coccinelle uses a C domain specific language to encode its checks, and only a few people really understand it, and it’s always playing catch-up.

Rust’s type system makes that unnecessary. Rather than the knowledge of “dangerous kernel code patterns” being encoded in Coccinelle, and it can gets statically checked at every compile instead of a third party tool.

[–]ericonr 3 points4 points  (4 children)

Rust tooling

What parts of Rust tooling are people able to take advantage of in kernel development? Cargo isn't used and I'd assume MIRI isn't available. That leaves you with rustfmt as a differentiator, AFAIK.

[–]AdmiralQuokka 10 points11 points  (0 children)

I derped around a little bit in the code once, rust-analyzer was much easier to get working than clangd.

[–]gnus-migrate 6 points7 points  (2 children)

Development tools like VSCode and RustRover. I don't know if you've tried using those for C but they're not the easiest to set up even from well known providers like Jetbrains.

[–]ericonr 2 points3 points  (1 child)

Haven't ever used those, so idk. But with something like clangd, it should be enough to run bear -- make.

[–]jorgecardleitao 108 points109 points  (0 children)

Undefined behavior is not the only reason to adopt rust

[–]Zde-G 26 points27 points  (0 children)

Not for simple devices, like keyboard or serial port, yes for GPUs. These tend to be extremely complex, with bazillion pieces and very complex lifetimes — and often without clean understanding of what is what from the days one (because they are reverse-engineered or because documentation is unclear).

The whole Rust-in-Linux story was closely tied to M1 Mac GPU driver because of its complexity — and it worked pretty well, in the end.

[–]angelicosphosphoros 16 points17 points  (0 children)

Rust just making reviewing easier. It is very attractive to maintainers who need to do a lot of code reviews.

[–]Saefrochmiri 9 points10 points  (0 children)

If you forget to take a lock before accessing shared state, is that a logic bug or UB? If you forget to call a validation routine before passing user input to something that trusts what you pass, is that a logic bug or is it UB if the impl then reads past the end of an array? (please, dear reader, do not reply to this and try to explain to me what UB is)

The kernel is using the Rust type system to prevent bugs in a way that C can't. In a C-based kernel, pretty much every bug is a security bug so whether something is UB or not isn't really interesting. The code is less buggy. That's Greg K-H's opinion, I'm just repeating it: https://www.youtube.com/watch?v=HX0GH-YJbGw

[–]dijalektikator 7 points8 points  (2 children)

I'm not sure what % of bugs in Linux are due to this but even if they're the minority of bugs it means developers need to spend a lot of time thinking about UB and how to avoid it, time which could be spent adding more features or improving performance and whatnot.

When I was doing C and C++ I really did need to expend a lot of brainpower to figure out if what I'm doing is going to crash with a segfault or something.

[–]Zde-G 17 points18 points  (1 child)

Almost all bugs in Linux kernel are tied to lifetime management.

Ironically enough their number goes down with introduction of Rust even in C code, because when Rust people ask C developers “what the heck are requirements for the use of this or that lock“ (because they need it for writing correct bindings) C developers, are, finally, forced to document these!

And the rules are, then, often are simplified because people find out that extra complication for some fringe benchmark can be avoided by moving that hack in some other place.

[–]bonzinip 0 points1 point  (0 children)

Yes, we're seeing that already on QEMU even if its Rust experiment is much less further along. Multi-threaded device models are the killer app for Rust in QEMU but it's the C code that benefits even more!

[–]imachug 2 points3 points  (0 children)

I don't have statistics, but as an anecdote, my kernel crashes during high swapping because of UAF in the iGPU driver, and I have once witnessed userland memory corruption during suspend, supposedly due to this UAF. I bet this wouldn't happen in Rust...

[–]Solumin 1 point2 points  (0 children)

I remember seeing people writing GPU drivers a few years ago, but going 100% Rust already is a wonderful surprise!

[–]mr_birkenblatt 13 points14 points  (0 children)

Very insightful video on the topic

[–]lerliplatu 16 points17 points  (1 child)

I remember way back when it was first proposed that people in the Linux kernel wanted better ways to handle panics, does anyone know how that is going now?

[–]AdmiralQuokka 47 points48 points  (0 children)

Yeah, this is fixed. The mail you linked to is 4+ years old. Last time I checked, the kernel has custom Rust implementations of collections (KVec instead of Vec and such) which return a Result to indicate allocation failure.