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

[kpedersen]

Considering the rest you listed, I suggest you have a look at what GTK did with its rust bindings.

Well this is kind of it. Though Gtk and also the OpenGL bindings are certainly good, they were non-trivial to implement (i.e it wasn't a case of simply running bindgen). I don't think we should be adding this additional working onto the Linux kernel maintainers (who are already short of manpower as it is).

Arguably Gtk was also designed with binding generation in mind. The Linux kernel was not.

To be fair, the fact that crates.io even exists is generally evidence that binding generators aren't quite enough or we would simply have it inbuilt into the compiler to access C libraries directly.

[bachchain]

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 ?

There are some instances where Rust will do things like add runtime checking for array accesses where it can't statically guarantee that the index will always be in bounds. If that isn't desirable, then most of those functions or operations have an 'unchecked' variant.

[oleid]

To be fair, the fact that crates.io even exists is generally evidence that binding generators aren't quite enough or we would simply have it inbuilt into the compiler to access C libraries directly.

Not really. Creating bindings is not the only thing you've to do. You also have to integrate the library to the build system. There is no cross-platform standard to

1. get all the dependencies of a C library you have to pass to the linker.
2. to call the linker
3. to build the C library if it is not available in the system (e.g. the bzip2 crate creates a static library and doesn't use the system lib).

All that logic is available in the published crates. No need to do it yourself.

Take meson for example. You'll find ready made wraps for lots of C libraries in their WrapDB, similar to crates.io

[cl333r]

As long it's not a requirement to have rust compiler installed, to be able to properly build mainline kernel, guessing it's OK.

I'd actually like Rust to replace C but not C++ because Rust simply doesn't cut it. Something as simple as a dynamic mutable tree which would take a minute to implement in C++, is next to impossible in Rust - I've spent 2 months and failed, because the naive online examples don't work IRL because of the borrow checker which makes to whole thing a total mess, to this day I haven't seen a viable Rust solution, Mozilla's own Rust code from WebRender uses a JavaScript backend for this.

[goTouch]

Fun time. I'd think if my hardware are all supported by C code in kernel, I'd want it continue to be so. Don't convert any of them to Rust.

New driver in Rust is fine as long as they are kernel module only. The mail kernel should be still be 100% C.

I always think driver modules should be shipped in separate tarball from kernel source. They can of course stay in same git repo. The kernel source tarball now is quite big and every one building kernel has to download lots of driver source code that is not used at all.

[oleid]

I'd actually like Rust to replace C but not C++ because Rust simply doesn't cut it. Something as simple as a dynamic mutable tree which would take a minute to implement in C++

There are plenty of trees on crates.io. You can always fall back to raw pointers for such stuff and provide a safe wrapper. Nothing wrong with that.

But I'm curious how you'd implement that in C++. Do you have a sample source of what exactly you have in mind at hand?

[Pajn]

I'd actually like Rust to replace C but not C++ because Rust simply doesn't cut it. Something as simple as a dynamic mutable tree which would take a minute to implement in C++, is next to impossible in Rust - I've spent 2 months and failed, because the naive online examples don't work IRL because of the borrow checker which makes to whole thing a total mess, to this day I haven't seen a viable Rust solution, Mozilla's own Rust code from WebRender uses a JavaScript backend for this.

If you really find it that difficult to think about a proper solution, just slap everything inside `Rc<RefCell<_>>` and call it a day. Or one step better, still without thinking, make all your structs internally mutable by slapping all mutable fields in `RefCell<_>` and just have all references as `Rc<_>`.

[cl333r]

If you really find it that difficult to think about a proper solution, just slap everything inside `Rc<RefCell<_>>` and call it a day. Or one step better, still without thinking, make all your structs internally mutable by slapping all mutable fields in `RefCell<_>` and just have all references as `Rc<_>`.

RefCell doesn't fix much because it doesn't cancel the borrow checker, it's just that it moves from being detected at compile time to runtime, so your problem moves from not compiling to randomly crashing because of the runtime error.

[oleid]

RefCell doesn't fix much because it doesn't cancel the borrow checker, it's just that it moves from being detected at compile time to runtime, so your problem moves from not compiling to randomly crashing because of the runtime error.

True, RefCell should only be used as last resort. But if it doesn't help in your example case, how do you prevent undefined behaviour in similar C++ code?

[oleid]

Well this is kind of it. Though Gtk and also the OpenGL bindings are certainly good, they were non-trivial to implement (i.e it wasn't a case of simply running bindgen).

The problem is that a C function signature alone does not tell you which contract you have to adhere to in order to use it correctly. If you're lucky, you'll find everything important in the documentation. But this is meta-information, which of course cannot be used automatically.

Therefore, bindgen creates _unsafe_ functions, which is in rust-speak "programmer-checked" code.

Additionally, there is another attempt to create safe interfaces to C++. But it is not entirely automatic. You have to define the interface manually.

https://github.com/dtolnay/cxx