LWN: Comments on "A first look at Rust in the 6.1 kernel"

A first look at Rust in the 6.1 kernel

flussence — Thu, 20 Oct 2022 15:52:29 +0000

> The first challenge that interested developers will run into is actually building that support. The kernel configuration process looks for the prerequisites on the build system and, if they are not present, silently disables the Rust options so that they will not even show in, for example, make menuconfig.

I've seen options (in older parts of the code, can't remember which) that display a line of informational text in the menu when the normal option is unselectable due to a non-adjacent thing. Perhaps that ought to be a generalised mechanism, because it could've saved me an hour or two of stumbling around trying to figure out how the LLVM LTO feature worked.

A first look at Rust in the 6.1 kernel

rsidd — Mon, 17 Oct 2022 08:42:02 +0000

The kernel has been buildable with LLVM clang for quite some time. Android, among others, builds it with clang. From the rust docs linked above, LLVM is recommended for building kernels with rust support: "Using GCC also works for some configurations, but it is very experimental at the moment."

But in any case, the question is of linking code compiled with gcc with objects compiled with clang or something else. In general, this is possible. The kernel may have special difficulties.

A first look at Rust in the 6.1 kernel

mkubecek — Mon, 17 Oct 2022 07:44:33 +0000

> IMHO It's just silly to ask the user about enabling a feature that doesn't make sense for his system, or can't be built anyway.

This logic makes sense for people who are configuring, building and running the kernel on the same system which is mostly kernel developers. For all others - i.e. vast majority - kernel is usually configured on one system, built on another and used on many different. For that use case, the old approach (resolving unusable config options at build time) made more sense than current one (resolving at configure time). To emulate the old approach, one can use the "dummy toolchain", set of scripts in scripts/dummy-tools/ which pretend to be gcc, linker etc. capable of everything needed. People configuring distribution kernels then run "make CROSS_COMPILE=scripts/dummy-tools/ oldconfig" to get reproducible config which works as a superset of what will be actually built. So the solution here would be providing a dummy rust compiler and everything else that is needed.

A first look at Rust in the 6.1 kernel

ceplm — Sun, 16 Oct 2022 18:50:59 +0000

Wasn’t the kernel quite GCC-centric? How does it work when GCC for Rust is still mostly non-existent?

A first look at Rust in the 6.1 kernel

flussence — Sun, 16 Oct 2022 15:47:29 +0000

Rust is a config-time check so I guess it'd be exactly the same as other toolchain probing: you can see the effect if you do `make LLVM=1 oldconfig`; it pops up a bunch of new clang-specific questions but the old gcc-plugin ones silently vanish without warning, and vice versa.

A first look at Rust in the 6.1 kernel

rsidd — Sun, 16 Oct 2022 07:43:45 +0000

About that Apple graphics driver... here's the writer's (Asahi Lina's) tweet thread on her experience with using Rust. Sample quotes

it's way more useful than I could've ever imagined! I went from 1st render to a stable desktop that can run run games, browsers, etc. in about two days of work on my driver (!!!)

There is absolutely no way I wouldn't have run into race conditions, UAFs, memory leaks, and all kinds of badness if I'd been writing this in C.
In Rust? Just some logic bugs and some core memory management issues. Once those were fixed, the rest of the driver just worked!!

I actually spent more time tracking down a single forgotten `*` in the DCP driver (written in C by Alyssa and Janne, already tested) that was causing heap overflows than I spent tracking down CPU-side safety issues (in unsafe code) in Rust on my brand new driver, in total.

Also of note: she and Alyssa Rosenzweig used this Rust driver (and Alyssa's kernel driver) on an M1 Mac Mini that they used to present their talk at XDC2022.

So, while the mainline kernel part may be rudimentary, useful drivers seem already to be here, and more important, there are some who find the environment useful in developing drivers.

A first look at Rust in the 6.1 kernel

khim — Sat, 15 Oct 2022 19:17:50 +0000

Have you you actually read the stable-api-nonsense?

It's summary is telling enough: You think you want a stable kernel interface, but you really do not, and you don't even know it… what you want is a stable running driver, and you get that only if your driver is in the main kernel tree (emphasis mine).

> With C this is a pipe dream, but with Rust pedantism and expressiveness throuh indirect (like asking for &Borrow<Q> instead of &reference, with implementation details left to a type), may be there is a hope.

C is not an issue. Both Solaris and Windows use C for their stable API for drivers but both face the same issue: once per few years some radical change in the hardware organization necessitates something radical which is not possible to provide without breaking APIs. Be it big kernel lock, addition of IOMMU or bazillion other radical changes.

At that point old driver model becomes broken anyway and you need to rewrite your driver anyway.

Instead of trying to deal with it in Solaris/Window fashion (there are many “driver models”, kernel supports few recent ones and obsoletes very old ones slowly) Linux uses different approach, Apple-style: we want to provide the most advanced and innovative platform to our developers, and we want them to stand directly on the shoulders of this platform.

I think this message from years where Linus was not sugar-coating his words explains situation even more clearly:

I want people to expect that interfaces change. I want people to know that binary-only modules cannot be used from release to release. I want people to be really really REALLY aware of the fact that when they use a binary-only module, they tie their hands.

Note that this point is mainly psychological, but it's by far the most important one.

Basically, I want people to know that when they use binary-only modules, it's THEIR problem. I want people to know that in their bones, and I want it shouted out from the rooftops. I want people to wake up in a cold sweat every once in a while if they use binary-only modules.

There are no compatibility layer which you hope to get from Rust not because of C deficiency but because kernel developers actively don't want to have it. And if they don't want want to have it then it wouldn't exist.

How can Rust language properties may affect that?

> I expect something like that from this imaginary framework. Driver code is the same for different kernels, framework knows all of kernels, actual binary representation changes wildly accordingly for kernel whims.

And what would happen when that magic would, finally, be stretched too far and fail? That is what Linus fights against:

Because I know that I will eventually make changes that break modules. And I want people to expect them, and I never EVER want to see an email in my mailbox that says "Damn you, Linus, I used this binary module for over two years, and it worked perfectly across 150 kernel releases, and Linux-5.6.71 broke it, and you had better fix your kernel".

See?

A first look at Rust in the 6.1 kernel

amarao — Sat, 15 Oct 2022 08:15:18 +0000

> Kernel is very explicit and vocal about that: all kernel APIs are unstable and there are no stability guarantees.

I understand, that things like removal of the global kernel lock are huge and can not be supported by any 'shim' between driver and the kernel, but for most changes, may be, there is a way to have 'all-knowing' framework with zero-cost (i.e. compile time) transformations which allow to use the same (driver) code for different kernels.

There is 'rkyv' zero-cost serialization/deserialization framework, which allow to work with external data without converting it. There is simple memory dump/load, and the serialization magic happens through careful memory layout of the data, orchestrated between all parties at compile time.

I expect something like that from this imaginary framework. Driver code is the same for different kernels, framework knows all of kernels, actual binary representation changes wildly accordingly for kernel whims.

The main motivation (the way I feel it) is to remove amount of nuances needed to know to write a driver. With C this is a pipe dream, but with Rust pedantism and expressiveness throuh indirect (like asking for &Borrow<Q> instead of &reference, with implementation details left to a type), may be there is a hope.

A first look at Rust in the 6.1 kernel

geofft — Sat, 15 Oct 2022 02:23:33 +0000

This is what we were doing with the predecessor project, more or less: https://github.com/fishinabarrel/linux-kernel-module-rust

It's not quite "cargo build" because there are some kernel-specific postprocessing steps to get a .ko that Cargo doesn't quite know how to do. (There's also some preprocessing that's theoretically doable in a build.rs but easier if you set up Cargo to be called from the kernel Makefiles.) But you could copy the scaffolding from the hello-world directory - Makefile, Kbuild, and Cargo.toml - and get something that worked.

It's probably a good time to document how to do out-of-tree modules in Rust using the in-tree build support, because that's a lot easier for someone who wants to get started on their current running system.

I don't see a way around the Kbuild file, though... but perhaps one could write a "cargo kbuild" subcommand that dynamically generates it and lets you keep your project using Cargo-style layout, to keep things familiar for people who know userspace Rust and not kernel Makefiles.

A first look at Rust in the 6.1 kernel

tialaramex — Fri, 14 Oct 2022 23:41:43 +0000

In particular, although core::ops::Drop::drop(&mut self) *looks* like a pretty ordinary safe trait function it is actually magic the compiler cares about - Rust calls such magic a "langitem" as in "language item". If you made your own my::Drop trait with a drop(&mut self) function anybody can implement that on their types if they want, and anybody can call that drop() method on values of those types, yet it won't de-allocate anything, won't happen automatically, it just has a misleading name, like the artwork "An Oak Tree". But the langitem deliberately cannot be called by people explicitly (that's a compile error), and it will get called automatically by the language when items of that type are about to be destroyed.

So logically this code happens because the kernel is destroying this value, if Linux actually keeps the value alive that's a kernel bug, it's logically OK if the kernel can't or won't clean up the RAM used for the module, but it definitely can't expect that the Vec still works for example since Rust will have recursively called Drop::drop on the Vec inside this type (and so on) and the Vec is presumably delegating to some kernel allocator to get suitable blocks of memory which it will then give back when destroyed.

A first look at Rust in the 6.1 kernel

NYKevin — Fri, 14 Oct 2022 18:49:19 +0000

> or else the borrow checker has not done its job correctly.

(Or, more prosaically, someone has violated the safety rules in an unsafe block or in native C code or something along those lines. "Unsafe" doesn't mean "I can do whatever I want," it means "the compiler isn't checking everything here, so I have to be careful.")

A first look at Rust in the 6.1 kernel

willy — Fri, 14 Oct 2022 18:41:52 +0000

This really isn't true. Depending what you're complaining about, Kconfig is twenty years old, not thirty. Roman Zippel rewrote it in 2002. The Makefiles were moved to their current declarative syntax around 2000. There are regular updates to the build system, including an active maintainer.

In summary, you have no idea what you're talking about.

A first look at Rust in the 6.1 kernel

NYKevin — Fri, 14 Oct 2022 16:58:52 +0000

In general (not specific to the kernel), that is never supposed to happen. By the time drop() gets called, your object should not be owned by anyone and nobody should have any outstanding references to it, or else the borrow checker has not done its job correctly.

A first look at Rust in the 6.1 kernel

Wol — Fri, 14 Oct 2022 14:25:39 +0000

> As a Rust lover I want to see the ability to build a kernel module with minimal amount of kernel stuff. If I need to put few bits into GPIO and create few entries for /sys, why should I dive deep into kernel build details?

Because, unfortunately, the kernel build system is over 30 years old, a mess, and has accumulated masses of technical debt? From what I've heard, that's not much of an exaggeration, if any ... and fair a few people have tried to fix it with varying degrees of success, but not really that much.

Sounds like you're not volunteering to make it easy for others to do what you want to do ...

I wish we had a simple "what hardware do you have" style config that you could just say "this is my processor, this is my mobo, these are my add-in cards", and it configured everything for you. The feedback I've got basically is "you'll need to rewrite pretty much everything ...". I hope things have improved, but I doubt it ...

Cheers,
Wol

A first look at Rust in the 6.1 kernel

khim — Fri, 14 Oct 2022 13:39:48 +0000

> I know, the thing I ask is selfish, but those selfish moments are actually breakthroughs. 'You can build a kernel module within this reasonable kernel framework and do not think about whole complexity of the magic behind the curtain'.

Note that the whole reason Rust is merged into the kernel now is specifically because something like that is just not possible. Kernel is very explicit and vocal about that: all kernel APIs are unstable and there are no stability guarantees.

> If I need to put few bits into GPIO and create few entries for /sys, why should I dive deep into kernel build details?

If your needs are so modest then why do you even need kernel driver in the first place? Linux have GPIO API and you can do everything without needing to write any drivers.

A first look at Rust in the 6.1 kernel

geert — Fri, 14 Oct 2022 13:22:45 +0000

In that case the Rust support will be disabled silently.
This behaves the same as when using a config file that has compiler-dependent support enabled which is not supported by your compiler (e.g. UBSAN_TRAP, see `git grep "\$(" -- "*Kconf*"' for more).

I guess that's fair enough for an experimental feature that is not yet supported on all architectures?

Note that personally, I never run "make oldconfig", but always use my "linux-oldconfig" script, which prints a diff of all changes between the old and the new config file.

A first look at Rust in the 6.1 kernel

mathstuf — Fri, 14 Oct 2022 13:13:06 +0000

What happens if I have a config file that specifies "please enable Rust support" on a machine without the prereqs? Is there some notification that I'm not getting the kernel I asked for?

A first look at Rust in the 6.1 kernel

amarao — Fri, 14 Oct 2022 12:00:41 +0000

As a Rust lover I want to see the ability to build a kernel module with minimal amount of kernel stuff. If I need to put few bits into GPIO and create few entries for /sys, why should I dive deep into kernel build details?

I really like to see a way to run 'cargo build' and to build a 'plain boring' module for the kernel.

I know, the thing I ask is selfish, but those selfish moments are actually breakthroughs. 'You can build a kernel module within this reasonable kernel framework and do not think about whole complexity of the magic behind the curtain'.

A first look at Rust in the 6.1 kernel

geert — Fri, 14 Oct 2022 08:32:09 +0000

There's no `--enable-frobnitz` switch that gets silently turned off in kernel builds.
IMHO It's just silly to ask the user about enabling a feature that doesn't make sense for his system, or can't be built anyway. And what about "allmodconfig" build tests and CI?
We already have close to 20000 config symbols, no need to bother users with the useless ones.

A first look at Rust in the 6.1 kernel

comex — Fri, 14 Oct 2022 08:13:03 +0000

rustup's behavior of modifying your startup scripts is not quite "silent". When you run the curl | sh, you get a pretty clear explanation:

> This path will then be added to your PATH environment variable by
> modifying the profile files located at:
>
> /home/comex/.profile
> /home/comex/.bashrc
> /home/comex/.zshenv

It then gives you options to confirm or customize, and one of the options to customize is whether to modify the startup scripts.

To be fair, this is only one part of a wall of text, so it's easy to skip past… but the rest of the text is pretty useful as well.

A first look at Rust in the 6.1 kernel

rsidd — Fri, 14 Oct 2022 04:21:12 +0000

Eg if it is in use by some other module? (Not sure whether that is what the article means)

A first look at Rust in the 6.1 kernel

quotemstr — Fri, 14 Oct 2022 01:14:28 +0000

> There does not appear to be a way for module removal to fail — which occasionally needs to happen in real-world modules.

Why should releasing resources ever fail?

A first look at Rust in the 6.1 kernel

Gaelan — Thu, 13 Oct 2022 23:55:11 +0000

> So in principle Rust for Linux could advise builders to use the stable Rust compiler, but just tell it to pretend it isn't a stable Rust compiler (one environment variable change), so as to take advantage of any QA benefits as presumably your distribution's stable Rust 1.62 compiler was actually tested while some random nightly (which has unstable features since it wasn't supported anyway) is not tested.

This is exactly what's being done.

A first look at Rust in the 6.1 kernel

tialaramex — Thu, 13 Oct 2022 23:06:37 +0000

Yes, Rust for Linux needs some unstable features. Rust for Linux tracks what is needed, since it is their long term goal that this will become unnecessary: https://github.com/Rust-for-Linux/linux/issues/2

Note that - while this is not a supported configuration - the stable Rust compiler is technically quite capable of compiling code using the unstable features which existed when it shipped, as this is exactly how it builds itself and its standard library both of which of course use unstable features. So in principle Rust for Linux could advise builders to use the stable Rust compiler, but just tell it to pretend it isn't a stable Rust compiler (one environment variable change), so as to take advantage of any QA benefits as presumably your distribution's stable Rust 1.62 compiler was actually tested while some random nightly (which has unstable features since it wasn't supported anyway) is not tested.

A first look at Rust in the 6.1 kernel

gray_-_wolf — Thu, 13 Oct 2022 22:17:45 +0000

I'm curious about the stability of rust's toolchain for kernel development. Does what has been merged still use unstable features? Or can you actually compile on stable rust 1.62.0? If no, are there any plans on how will the rust version support looks like? 1.62.0 forever? Or on other side of something like only latest and latest - 1?

A first look at Rust in the 6.1 kernel

xav — Thu, 13 Oct 2022 21:38:41 +0000

A small clarification: the Drop implementation is totally optional. In this example you clearly see it does nothing of value except printing logs; you could just omit it, the compiler will generate the necessary code for you (here, it will free the memory allocated for the numbers as well as properly finalizing the module).

A first look at Rust in the 6.1 kernel

sigma914 — Thu, 13 Oct 2022 21:35:00 +0000

This is exactly how most people I know install rustup, unless they're on Debian where the exact way they want it packaged is still under discussion.

A first look at Rust in the 6.1 kernel

mathstuf — Thu, 13 Oct 2022 20:21:44 +0000

> The "getting started" page describes how to do this; inevitably, it involves one of those confidence-building "curl|bash" operations. The installer is entirely uninterested in where one might like one's Rust stuff installed (it goes into ~/.cargo) and silently modifies the user's Bash startup scripts to add the new directory into the PATH variable. The end result does work, though, and makes it easy to install the needed dependencies.

Note that it is possible to get a `rustup` that doesn't muck about with one's setup. It does mean doing `curl -O` instead of `| bash` (or did when I set things up years ago; it gets rsync'd around on machine initialization now as it is self-contained at least) and some light editing to neuter global `PATH` editing and rerooting to `~/misc/root/rustup` (for myself). But it isn't a forced treadmill.

> The kernel configuration process looks for the prerequisites on the build system and, if they are not present, silently disables the Rust options so that they will not even show in, for example, make menuconfig.

Ugh, I hate this pattern. I've found "let the user request what they want" and "error if not satisfiable" to be a far better behavior because having a configure line that says `--enable-frobnitz` which turns itself off if it doesn't find the obscure `quuxness` dependency is a wonderful way to frustrate build script authors as new dependencies get added because "it worked last week".

A first look at Rust in the 6.1 kernel

xi0n — Thu, 13 Oct 2022 19:04:15 +0000

> it involves one of those confidence-building "curl|bash" operations

If all that's needed is rustup, it should be possible to get it from your distro's package manager, through the usual `apt install rustup` or similar. Particular Rust toolchains, including 1.62 to build the Rust kernel modules, could then be installed from rust-lang.org using that distro-installed rustup.

A first look at Rust in the 6.1 kernel

kees — Thu, 13 Oct 2022 14:57:27 +0000

C kernel module removal cannot fail either:

include/linux/init.h:typedef void (*exitcall_t)(void);

Real-world module exiting is controlled via the mount usage count -- it's only callable if the count is zero.