A first look at Rust in the 6.1 kernel [LWN.net]

A first look at Rust in the 6.1 kernel

Posted Oct 14, 2022 12:00 UTC (Fri) by amarao (guest, #87073)
Parent article: A first look at Rust in the 6.1 kernel

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'.

to post comments

A first look at Rust in the 6.1 kernel

Posted Oct 14, 2022 13:39 UTC (Fri) by khim (subscriber, #9252) [Link] (2 responses)

> 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

Posted Oct 15, 2022 8:15 UTC (Sat) by amarao (guest, #87073) [Link] (1 responses)

> 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

Posted Oct 15, 2022 19:17 UTC (Sat) by khim (subscriber, #9252) [Link]

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

Posted Oct 14, 2022 14:25 UTC (Fri) by Wol (subscriber, #4433) [Link] (1 responses)

> 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

Posted Oct 14, 2022 18:41 UTC (Fri) by willy (subscriber, #9762) [Link]

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

Posted Oct 15, 2022 2:23 UTC (Sat) by geofft (subscriber, #59789) [Link]

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.