Do you think Linux at some point uh might support Rust or and you know what what are your your what is your thinking of doing things outside of C?

>> So we have 25,000 lines of Rust in the kernel already.

>> Oh, we do.

>> Okay, awesome.

>> Yeah. Um so most of that is just bindings. There's no real functionality.

Um in the latest release, um if the kernel crashes, it'll put up a QR code.

You can take a picture of it to get the crash jump. That code was written in Rust.

>> Oh, nice.

>> Um that's in Rest. Um so the rest the perinx developers have been working for a long time. A couple years ago they came to us and said we think we have we think we're ready to do this. Do you want it? And we said yeah let's try this experiment. You're willing to do the work. Who am I to tell no to? Um I mean it's classic.

>> Yeah. I mean it's it's it's now the problem with Linux and Rust is

>> um it would be easier to write a core piece of Linux and Rust than it would be to write a driver. that drivers consume from everywhere in the kernel.

>> So you want to talk to locking, you want to talk input and output, you want to talk talk to the driver model, talk to the USB port, all this stuff. Drivers have to can be really tiny because they take resources from the rest of the kernel.

In Rust, you need to have a binding between the C code and the Rust code. There's an intermediate layer.

The C the kernel in C has these very opinionated model ideas of how it handles objects and how it does memory and how it it has its memory model. Rust has its very opinionated model of how it does this type same idea. This meshing is tough.

>> This meshing is also the most crazy complex Rust code you've ever seen. So from a new Rust developer like me, I can barely read the bindings, but I trust other people are doing it. Um, so yes, so the trick is we now need to write a binding for every different part of the kernel in order to write a R scope, a rush driver. If you want to do the QR generator, that's simple. That was just one function. you go.

>> So over the year, the past couple years, people have been writ bindings to try and do things. We've had a bunch of example drivers like a new disc driver, this writer driver in C versus Rust. It turns out there are still some performance issues with R code versus C code because we can do some tricks in C that they can't do yet in R.

>> Yeah.

>> Um that's and the tooling and the RS developers are doing it. The core RS developers that the language, some of them are Linux kernel developers. They've always wanted R to be working for Linux. Um the rest model is good.

Memory safety at our level does not mean that you can't crash the kernel. Uh you can still overwrite things. It memory safety in Rust just means the the memory that you pass around you think you have an ownership of or it isn't an ownership of.

>> Y

>> and it when things are go out of scope, they'll get cleaned up properly. So I've seen every single kernel bug for the past 18 years. Um half of them will be fixed with Rust.

>> It's just it's just going to be fixed with Rust. Um, it's the stupid oneoff bugs. It's the I Oops, I overwrote an array and I didn't realize it by one.

Oops, I um forgot to clean up this error path.

>> Yeah,

>> I forgot to unlock this lock. It's I It's stupid little things like that. There's logic bugs. Of course, you can write logic bugs in Rust.

>> You'll always have those,

>> right? So, but famously, the code the QR code for that did in Rust that made a QR C passed into the Rust code a pointer to a buffer and the buffer size. the Rust code forgot to look at how big the buffer was and it scribbled right over memory. So you can write memory unsafe code in R just fine and you can crash things in Rust. So memory safety here means it's the safety of object life cycles and things like that. It doesn't mean it's going to remove all bugs. It's not a golden um bullet or anything like silver bullet. But I think yes I think Rust needs to come in because it should be easier to write drivers in this stuff.

We have a lot of issues with lifetime rules of when you yank out a device, devices are dynamic and dealing with these reference counting of things like that is very tricky to get right. There's parts in the colonel we still do not have it right and we know we don't have it right.

>> Rust is forcing us to actually document our C code better

>> and it's cleaning up. So if Rust disappeared tomorrow, I've had to clean up code in the driver core. It's like, oh yeah, I guess we can do things better and safer in the C code in order to make Rust easier. Mhm.

>> And we have and so it's making us rethink how we do a lot of our existing code in the kernel. To be fair, a lot of core kernel people are very resistant to that. They don't like change, don't like different languages. Um, one core kernel developer said, "I don't like working with a project that has um multiple languages in it just because it's tricky and they are free to do that." Um, we're not stepping on they're not stepping on anybody's toes. Um, a lot of it's miscommunication and a lot of it comes down to people. Again,

>> famously in this binding, I wrote the driver core many, many years ago of how drivers worked in the s in the kernel. There had to be a binding for that in Rust.

>> I this code I saw I said, "This is horrible. This isn't going to work at all. It's miserable." And um I went and actually met with the developers and we had there's a Rust Linux conference. We sat down. I think they gave a whole presentation just for me. Um turns out I was wrong and they were wrong. we both were wrong. And they were doing crazy things like they had a thousand lines of C Rust code that that I do in two lines of CC code. I'm like, well, why? They're like, well, we didn't want to change the CC code. I'm like, we can change the C code because I just did that because it was easy in C, but if I change that, you get rid of a thousand lines of R. Let's do that. And again, it comes down to, okay, understanding what your problems are, understanding what my problems are, and let's work together. And now we have bindings in the kernel that you can actually write some drivers with. And the Red Hat developers are starting to write the new Nvidia GPU drivers in Rust and they're starting putting the proposals out there. The Apple um um GPU drivers are for the Apple MacBooks are written in Rust. Those patches are not merged, but they're written in Rust and Prove on on a fork. Um that works great. Um there's a whole bunch of crazy object life cycle issues with graphics drivers and Rust makes it a lot easier for them to do. Um, I think you'll see a lot more of the driver simple stupid drivers for hardware devices being written in Rust because all you want to do is read and write to some random memory bits and it's really easy to do that in Rust and you can do it in actually less code than you can do it in C code.

>> Yeah.

>> And I think that's we now have the infrastructure in there. So I think we've hit the tipping point. We'll start seeing new stuff in there and we need to do that. I mean there's mandates from governments that you can't use memory unsafe languages like C and products.

>> Yeah. And if I want to see Linux to succeed, which I do, we're going to have to change. And I can say going forward, if you want to write in rest, you can write in rest. Now, that being said, we still have 40 million lines of C code.

Yeah.

>> So, we have some very, very good developers out there working on mitigating the problems we have in C. We now have bounds checking for our stuff. We now have other, we call them seat belts and airbags that protect your C code from doing stupid things. And we working with the compiler authors to add new extensions to C and make things safer for the C code because we want to protect the code that we have today because you're not going to rewrite code in Rust. Don't worry about that. Um Google famously published something recently saying over the past couple years we've written our new code in Rust and we got uh overwhelmingly more secure because we didn't touch the old code and bugs degrade over time. There's still going to be bugs in the older stuff, but most bugs happen in your new code, not in your old code.

>> That's awesome. I'm I'm I'm sensing you're you're excited about Russ and I I it's also just nice to see the evolution.

>> Yeah, it's evolution and see what happens and if it fails tomorrow, we can rip it out and what but we have developers willing to do this work for us.

>> It's not intruding on other people's stuff.

>> Well, then I I I think it does go back to what you said earlier is is it's feel I understand that a big part of Linux is like show the work like if if if it works and and same thing, you know, it sound like that's how Rust started and how it's also how it's progressing. People are showing that it works. They're proving that it works, it solves their problem. Yeah. It maybe even works better for them. And then, you know, step by step.

>> Yeah. Like people are like, well, why not Zigg or Hair? Those are other good languages. Um, I'm like, that's great, but nobody's proposed.

>> Yeah. [laughter]

>> So, yeah, they want to do that. And to be fair, I think those developers who work on those languages don't care about Linux, which is fine. They'll not you.