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