Linus Torvalds' Initial Comment On Rust Code Prospects Within The Linux Kernel

[p91paul Junior Member Find all posts View Profile Close p91paul]

and nothing works, that's why nothing but c++ is used as viable replacement for c
i didn't say "call c code", i said "understand c headers". even perl can "call c code"

A quick Google lookup will teach you that Rust bindgen *understands C headers* and generates Rust bindings from that.

[Guest Close Guest]

Ok, but how is the code written in Rust compared to C at the performance level ?
Is Rust adding any safety checks at runtime that makes the code slower based on the assumption that the code is badly written ?

Rust's safety checks are statically analyzed. Compilation time is a bit slower, but there aren't runtime checks. Features involving dynamic casting are always expensive, whether written manually or supported by language.

[p91paul Junior Member Find all posts View Profile Close p91paul]

well, it has to be disabled by default because gcc 4.9 doesn't support it

I don't see why that's an issue. Once some non optional part of Linux gets written in Rust, you'll need a rust compiler to build it. That required compiler might not be under the GNU Compiler Collection umbrella.

[kpedersen Senior Member Find all posts View Profile Close kpedersen]

A quick Google lookup will teach you that Rust bindgen *understands C headers* and generates Rust bindings from that.

It generates "a good start" but for anything remotely complex you need to spend a large amount of man hours to solve.

Things like:

• C-style callbacks
• Opaque pointers
• Type-casting to first internal struct (poor man's oop)
• Non-owning arrays
• Multi-threading

All while, what you get out is completely 100% "unsafe". So you then need the "fat binding" on top which takes even more man hours before you can start to get the benefits.

I don't actually mind rust in the kernel. I am a bit weary of bindings becoming unmaintained and in the way. I honestly think the reason why other languages haven't managed to beat C/C++ in multiple domains is because they don't include the ability to consume C headers. I strongly believe that Objective-C will ultimately outlive Swift for this same reason.

If we can all migrate to Rust as the "defacto native systems language", I will be very pleased! I just think binding generators is the wrong approach and just breeds language package managers like Crates.io, NPM, PIP, CPAN which simply rack up technical debt with dependencies and screw project lifespans and deterministic development.

[Weasel Senior Member Find all posts View Profile Close Weasel]

First the inclusive bullshit, now this?

Linux is really doomed, I guess.

[andyprough Senior Member Find all posts View Profile Close andyprough]

All part of the effort to get the kernel to run as fast and as well as firefox

Maybe mozilla should be in charge of developing the kernel going forward.

[oleid Senior Member Find all posts View Profile Close oleid]

Linux is really doomed, I guess.

No, Weasel is.

[oleid Senior Member Find all posts View Profile Close oleid]

It generates "a good start" but for anything remotely complex you need to spend a large amount of man hours to solve.

Things like:

• C-style callbacks
• Opaque pointers
• Type-casting to first internal struct (poor man's oop)
• Non-owning arrays
• Multi-threading

All while, what you get out is completely 100% "unsafe". So you then need the "fat binding" on top which takes even more man hours before you can start to get the benefits.

It all depends on how you do it. Non-owning arrays are easy. They are called slices in rust. Typically represented via a pointer and a length in a FFI.

Also, there is nothing wrong in calling functions marked unsafe in your driver. You just have to check the functions requirements yourself.

Considering the rest you listed, I suggest you have a look at what GTK did with its rust bindings. They did lots of experimentation how to wrap C stuff idiomatically, but they turned out pretty nice, IMHO. You can even run rust futures (or async functions for that matter) on a glib based executor.

EDIT:

Async functions also work nicely with interrupts. The interrupts can wake some async task when it has new data. The following (from the Writing an operating system in rust blog series) is a good read. They show how to implement a keyboard driver:

https://os.phil-opp.com/async-await/

[Veto Senior Member Find all posts View Profile Close Veto]

It is all a conspiracy. The world is coming to an end! We are getting opressed.

Seriously, Rust looks like the biggest innovation in _systems_ languages in years, and Linus not having a fit about it speaks volumes...

[andyprough Senior Member Find all posts View Profile Close andyprough]

"Sorry, I won't be able to start your OS today, Dave. Please run 'source $HOME/.cargo/env' and 'cargo install cbindgen', recompile your kernel, and try again"