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

A first look at Rust in the 6.1 kernel

Posted Oct 15, 2022 8:15 UTC (Sat) by amarao (guest, #87073)
In reply to: A first look at Rust in the 6.1 kernel by khim
Parent article: A first look at Rust in the 6.1 kernel

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

to post comments

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?