Greg Kroah-Hartman Sees 'Tipping Point' for Rust Drivers in Linux Kernel

Greg Kroah-Hartman noted some coming changes in Linux 6.13 will make it possible to create "way more" Rust-based kernel drivers. "The veteran kernel developer believes we're at a tipping point of seeing more upstream Rust drivers ahead," reports Phoronix: These Rust char/misc changes are on top of the main Rust pull for Linux 6.13 that brought 3k lines of code for providing more Rust infrastructure. Linux 6.13 separately is also bringing Rust file abstractions.
"Sorry for doing this at the end of the merge window," Greg Kroah-Hartman wrote in the pull request, explaining that "conference and holiday travel got in the way on my side (hence the 5am pull request emails...)" Loads of things in here...

— Rust misc driver bindings and other rust changes to make misc drivers actually possible. I think this is the tipping point, expect to see way more rust drivers going forward now that these bindings are present.

Next merge window hopefully we will have pci and platform drivers working, which will fully enable almost all driver subsystems to start accepting (or at least getting) rust drivers. This is the end result of a lot of work from a lot of people, congrats to all of them for getting this far, you've proved many of us wrong in the best way possible, working code :)

Yep, bringing an unstable language in...

[gweihir]

... is such a great idea. I am still convinced Linus is essentially just giving the Rust-fanatics enough rope to hang themselves.

Re:

[fluffernutter]

Yup, it has taken linux 30 years to get this far, but hey let's mess with it.

Re:

[Jeremi]

Yup, it has taken linux 30 years to get this far, but hey let's mess with it.

It took linux 30 years of people messing with it to get it this far. You can't improve things unless you are willing to change things.

Re:

[fluffernutter]

How is it an improvement to add a memory safe language in a field where people already understand how to handle memory? Anyone programming at the os or driver level will understand that. In the application layer maybe not so much.

Re:

[gweihir]

Well, sort of. The kernel core (for lack of a better word) is has basically no need for Rust, anybody able to do anything there is highly competent and generally does not make beginner's mistakes. On the other hand, drivers are a bit of a different story. But remember that drivers are easy to rip out, so this is more "Rust on the side of the kernel" than "Rust in the kernel", no matter the propaganda crap the Rust fans are pushing.

My take is this will eventually, in a few years, fail. Rust is too hard to le

Re:Yep, bringing an unstable language in...

[test321]

Rust in linux will bring more stability to the language because the backers of the Rust foundations are also important contributors to the linux kernel (Google, Meta, Huawei, Microsoft).

Re:

[gweihir]

Probably. But that is ass-backwards.

Re:

[PPH]

Rust in linux will bring more stability

Or it will kill linux. Much to the joy of Google, Meta, Huawei, and Microsoft. Who I'm sure have proprietary solutions waiting in the wings.

Re:

[test321]

I don't believe that Google or Meta are interested in complicated ways to kill linux. They could replace linux with something else any day they want in the clear without strange conspiracies, yet they're not doing it. Amazon is also a backer of the Rust foundation, and although it is not a contributor, it is a heavy user and does not want to disrupt its cash flow with a failing linux.

Microsoft might want to kill linux, but then money talks and Azure is their cash cow, like AWS for Amazon.

Your argument might

Re:

[phantomfive]

Google, Meta, Huawei, Microsoft

These are not the groups I would rely on to keep things stable.

Re:

[rta]

what's the state of cross-compilation?

last thing I cross compiled was an opener image like 10+ years ago, by I'd think with the level of virtualization, and just general improvements in tooling it would be the rule for any CPU/ram/Io constrained devices/platforms

Re:

[rta]

ugh... openwrt, not opener.

Re:

[Phillip2]

Rust is only being used for drivers, so if you want to drivers for a platform which the Rust toolchain doesn't support either at all or in practice, why would you write drivers for it in Rust? Unless you expect to build for that platform with cross-compilation in which case neither building the toolchain nor building with it won't be much of an issue.

Re:

[gweihir]

Yes. Rust is, at this time, carefully walled in, with no need to use it at all. Rust can also probably be ripped out without too much damage.

The other thing is that drivers are a _major_ point of problems (security and otherwise) in the kernel, so maybe Rust will serve as a skill-gate there, since it is pretty hard to learn and cumbersome.

Re:

[thegarbz]

You don't need to be on a platform to build something for that platform. No one here is proposing you compile the kernel on a raspberry pi zero. Use your desktop PC to do that - FOR YOUR OWN SANITY.

Re:

[Waffle Iron]

Stability is of paramount importance.

I demand to be able to compile and run the exact same segfaults that I was writing in 1974!

Re:

[phantomfive]

Maybe not 1974, but if you compiled something in 1997 for Linux, it will probably still run. (If it doesn't, it's because you relied on unstable libraries from Gnome or something). The Linux kernel has made userland stability a priority, and with success.

Re:

[gweihir]

Indeed. As good engineering practices would dictate. Of course, if you want to make tons of money selling software, you have to force people on new software and platform version all the time, thereby crappifying the quality of it all.

Re:

[phantomfive]

For that matter, there's a reasonable chance you could get a 1974 C program to compile on GCC with the right options; certainly a 1978 program could be compiled. (Incidentally, Donald Knuth prefers K&R C over ANSI C, I think he likes the syntax better somehow).

Re:

[SoftwareArtist]

Nothing about this will affect userland. The public APIs aren't changing.

Re: Yep, bringing an unstable language in...

[unfriendlyLLM]

Or wrap in in a pagefault, so you can have it in a return value. Then hide it some app helper's i/o stream. Then you can have some platform built around it.....

OK, as long as I don't need a rust compiler.

[Gravis Zero]

So long as the Rust is 100% optional for compiling the kernel except for a few oddball modules, I'm OK with this. When something critical becomes Rust only, I will be very much against this because it means needing multiple compilers just to build a the dang kernel.

Re:

[thegarbz]

You're implying the kernel isn't already complex to build, requiring downloading a large toolset and a relatively powerful computer (to preserve your own sanity). The people building their own kernels are not usually the type to build only a kernel.

I don't see any reason why you would draw the line at one compiler. It's a senseless line to draw.

Re:

[Gravis Zero]

I don't see any reason why you would draw the line at one compiler.

It's not that it's one compiler, it's that it's the only compiler. It's bad enough that GCC is the only C compiler that can build Linux (despite efforts to make Clang capable) but to make two specific compilers to build the kernel is nuts and completely destroys any chance of build portability.

Re:

[myrdos2]

We should then rewrite the kernel entirely in Rust. I predict that this will make you happy.

Re:

[martin-boundary]

In other news, Lennart Poettering has just announced that systemd will be completely rewritten in Rust, starting in January.

Re:

[butlerm]

I will be sufficiently impressed with Rust when one can successfully do a nearly one for one translation of C and/or C++ code to idiomatic Rust code without breaking anything. Until then not so much. Of course many such functions would necessarily be unsafe but certainly not all of them, even in a code base like the Linux kernel.