Long long ago in the ancient times of 2021
We saw the first attempt at bringing Rust support into the kernel
RFC Rust support RFC meaning request for comment
This was being done through the Rust for Linux project now at the time there was a lot of feedback on the patch set and
That really hasn't changed since then but at the time it
Definitely needed that feedback because it was not ready for upstream. It wasn't even ready for an RFC
this shouldn't have been anywhere near the Linux kernel because
Rust's biggest benefit is all of the whole memory safety stuff over C
But it was doing stupid things like if you ran out of memory
It would just throw a panic and abort that should never happen at the kernel level
It's fine in user space, but the kernel was a different beast with the main point of Rust being safety
There is no way I will ever accept panic dynamically whether due to out of memory or due to anything else
I also reacted to the floating point use cases dynamic panics as a feature in the Rust model now
This is what you expect from a very early RFC
Things don't usually get merged straight away
Things have to be redone to fit into the kernel and that's exactly what happened after that original RFC
There were ten different versions of the patch set sent up the kernel all trying to get reviewed all trying to get merged
All getting a lot of feedback before finally being ready to merge in the six dot one window
But this was still very early days what existed at the time was effectively the hallow weld version of this infrastructure
It was not ready for full-on drivers yet
That was still gonna come way later down the line as little bits and pieces get merged as
various different projects need to make use of the Rust infrastructure as is often going through the case in a big
Long-running project with maintainers who've been in the project for in some cases 30 or so years
There are people who are very for and
Very against these changes. Yes
Linus Torvalds did accept the merger into the Linux kernel and at the end of the day his word is law
But different subsystems have their own sort of
Independence they can choose to make use of things and choose to not and it's not been accepted by all subsystems and
Some of the subsystems are a little bit more against it than others. Let's talk about the recent Rust drama
Wedson retiring from the Rust for Linux project now Wedson has basically been involved in it from the start
He's been a very big driving force in actually making it happen
Putting a lot of effort into the project is one of the de facto leaders of the project
This is not something that happened because of a one-off interaction a one-off bad conversation
This is something that has been built up
Over all of this time working on the Rust for Linux project
This is a shorter series as one can be just removing myself as maintainer of the Rust for Linux project
I am retiring from the project after almost four years. I find myself lacking the energy and enthusiasm
I once had to respond to some of the non-technical nonsense
So it's best to leave it up to those who still have it in them to the Rust for Linux team. Thank you
You were great. It was a pleasure working with you all the times we spent discussing technical issues
Finding ways to address soundness holes, etc. Was something I always enjoyed and looked forward to I count myself lucky to have
Collaborated with such a talented and friendly group. I just noticed the spelling mistake
I didn't spot that one before I wish all the success to the project
I truly believe the future of kernels is with memory safe languages
I am no visionary, but if Linux doesn't internalize this
I'm afraid some other kernel would do it what it did to Unix
Lastly, I'll leave a small 3:30 sample of context here and to reiterate
No one is trying to force anyone to learn Rust nor prevent refactorings of C code a
Lot of people saw this clip and assumed this was the entire reason this happened. It's not
But it serves the good example most notably this part right here. So let's just have a quick
I'm not trying to force new ways of specific ways of doing things. We're encoding how things are done in the I get locked example here
Right, that's this is early days. We're not trying to boil the ocean here. Yeah
We're almost out of time here, and I thought this who you're listening to is Ted Ts'o who is a very prolific
Kernel maintainer. This is the part that a lot of people got very annoyed by I suspect part of the problem here
Most specifically the people who really care about Rust got very annoyed by is you're trying to convince everyone to switch over
to the religion as
promulgated by Rust and the reality is that ain't gonna happen because we have 50 plus file systems in Linux
They will not all be instantaneously converted over to Rust before that happens
We will continue to refactor C code because we want to make the C code better if it breaks
Just pay attention to these speakers as he's talking like they just want to get a word in he's not letting it happen
bindings at least for the foreseeable future
The Rust bindings are a second-class citizen and those file systems that depend on the Rust bindings will break
And that is the Rust bindings problem
Not the file system
Community at large problem and that's going to be true for a long long time
Okay, and I think we just simply need to accept that right because the answer
You are not allowed to refactor to the C code because it would break five critical files. I said they're like, let me talk
Let me just respond to what you're saying systems that discros depend upon
Is like not a starter. Okay, so like we'll see I I suspect the best thing to do is you to continue maintaining your Rust bindings
Over time there will be continued
C code refactoring, right? Maybe we will start using, you know
Our k free rcu if that breaks Rust
We will find out whether or not this concept of encoding huge amounts of semantics into the type system
Is a good thing or a bad thing and instead of trying to convince us
What is actually correct?
Let's see what happens in a year or two and it will either work or it won't and we will see
More likely where does the pain get allocated because with most of these sort of engineering things
It's almost always a pain allocation question
So tell let me try to to respond to that. I'm not saying that C is going to be uh,
Stuck in whatever it has. That's not what I'm saying. Yeah, I actually what I'm trying to say is I want to
For you guys to tell me, uh, what the semantics are of these things that we reflect in Rust. That's that's all I'm saying
No, no, no, no, no
From my point of view, it's the same of any user, right users of these apis
They they have to know about the semantics and they have to use them, right?
And the rule is if you make a change a semantic change you have to go and fix everybody else who who you have broken
He is the big
He's the real big part
While rest is a second
Class citizen, I'm fine for you guys to say we will not care about this. Uh, you guys should here's the thing
You're not going to force all of us to learn Rust if I make a change
I will fix all of the c code because that's my responsibility
Because I don't know Rust where I know we're okay with Rust bindings. Sorry
Let me try to say it more clearly. I'm not trying to force you or anybody else to do anything else, right?
I'm just asking you to see if you guys could give us semantic information. That's that's all I'm asking
guys, uh
This is such a great argument. I absolutely love it
Okay, let me explain what was going on here
If you want to have Rust bindings in a project c bindings in a project Java bindings, Python bindings anything else
These don't just magically happen
These need to be written and these need to be maintained now from the Rust perspective
They want to have this semantic information of how these functions should be used
So they can encode that information
Into the function signature itself
So this makes it a lot clearer how to actually make use of these functions
How to interact with the kernel and this is one of the benefits of a language like Rust that often doesn't get discussed
because right now a lot of the kernel documentation is kind of just like
Not really there and you go to examine the source code to know things like does this function accept a null?
Does it accept the negative value if it accepts a negative value?
Does a negative value actually mean something special?
You can encode a lot of this information into Rust and make it a lot easier to work with things now from the c side
They don't want to have to deal with Rust because well they're c developers and they don't know Rust
So they see these Rust bindings as really fragile because if they go and refactor a function signature
All of a sudden that Rust binding is now completely broken
And they don't want to have to go and maintain a thing that they don't have the knowledge of that
They probably are going to make mistakes on as well
And they feel like there's going to be a lot of additional pain that is being allocated around to people who just don't want to have to deal with it
There are a lot of people very heated on both sides of this discussion
And I think the part being often forgotten is both sides make a really good point
The c people are making good point about making these functions easy to use
Encoding how the function should be used into the function itself
The c people make a really good point about these functions being really fragile and
The pain not really being clear where it's going to be allocated
And it's one of those often cases where things honestly could probably be resolved if people just sat down
And talk to each other not making hot takes on twitter and mastodon
Not going and like talking shit about people without really thinking about their perspective
Not straw manning anyone else's argument sitting down
Better yet if you can in person talking if not over a video call and just
Try to understand what the other person is saying try to come to a reasonable conclusion here
Try to come to a reasonable middle ground
Since that is not happening
I would like to highlight a couple statements that various people involved have put out the first one being from
Asahi Lina a subset of c kernel developers just seem determined to make the lives of Rust maintainers as difficult as possible
They don't see Rust as having value and would rather it just goes away
When I tried to upstream the DRM abstractions last year
That was all blocked on basic support for the concept of a device in Rust
Even just a stub wrapper for a struck device would be enough that simple concept only finally recently got merged
Over one year later when I wrote the DRM schedule abstractions
I ran into many memory safety issues caused by bad design of the underlying c code
The lifetime requirements were undocumented and boiled down to design your driver like AMD GPU and make it work
Or else, my driver is not like AMD GPU
It fundamentally can't work the same way when I tried to upstream minor fixes to the c code to make the behavior more robust
And lifetime requirements sensible the maintainer blocked it and said I should just do what other drivers do
Even when I points out that other c drivers also trigger the same bugs because the api is just bad and unintuitive
And there are many secret hidden lifetime requirements. He wouldn't budge one c driver works
So Rust drivers must work the same way
Next we have jerry soler of System76 a big engineer in the COSMIC project and also the lead developer of
RedoxOS a system entirely built around Rust Rust applications Rust desktop Rust kernel
Everything is Rust this kind of treatment is exactly why I started Redox with scratch and written primarily in Rust
There is a lot of resistance to even minor beneficial change in Linux and related projects
I don't even try to contribute to the Linux kernel anymore
There are projects where you'll never really have to get changes past patronizing pedantic megalomaniacs
And while the Linux kernel is not only developed by this personality type it is overwhelmingly controlled by it
I have no fond memories of submitting patches there
Whereas I find contributing to most Rust projects to be downright delightful
Next is Lyude Paul an X.org foundation board member, Mesa, Wayland, and upstream Linux kernel developer
Okay, actually serious post about Rust Linux now. No more kissy. There is something I realized just now
I should be saying in the midst of all this debate
I don't think the majority of people in the kernel are bad far from it
I literally wouldn't be here if I thought that the people I've worked with in this community
Are genuinely some of the nicest people I've met and are incredibly skilled at what they do
So understand when I'm talking about Linux and the problems
I really am doing so because I think it's all going to burn down or it's always like this. I'm concerned. Yes
It's about interactions that define how people see the kernel at large
I'm concerned about this isn't just for drem either
I should specify drem when we're talking about Linux kernel is direct rendering manager not digital rights management
While I think drem is honestly kind of really on top of a lot of stuff in ways
I wish the rest of the kernel was but like it's not like I'm going into other kernel communities
And fighting an endless war or something like that
I promise I literally wouldn't have the energy in me to even do that if I wanted to
But it can be really difficult to talk about the problems
I've seen without coming across as such because so often minor problems can lead to big backlash
Not just in public reception, but also in how people who ran into said problems
Actually feel about things overall
It can be really easy to forget this too when a lot of social issues tend to be like this
So much of public relations has less to do with direct fact versus direct impact
One person in a crowd of people can still define the way that entire crowd is viewed
So long as they hold some level influence there and have a voice
It can be illogical
But at the end of the day the end result is usually the only thing that makes a different
It is Plato's Cave if the only source of information you can get is negative
It might as well be a fact not only that but just like in the cave
If someone escapes from it and sees the person making the shadow puppets they may just not believe it
They can go back in the cave and the shadows are still there
Here is Karol Herbst a Mesa and Noveau developer
Maybe at some point I should talk about some of the pushback
I've gotten when I proposed Rusticle to be merged into Mesa
But all in all I think we can safely say that introducing Rust to Mesa as a success
I don't know how much that impacted Faith Extrand and writing NAK in Rust
But at least I've dealt with some of the mason and Rust integration problems early on
So at least I enabled that to be a bit simpler than if I hadn't done that
Carol's take here is just generally about working with Rust
But he has been reposting a lot of the other takes we've seen before
So it's pretty clear what his stance in the situation is
And Dave Airlie wrote an entire blog post about the different kinds of people you run into in the kernel
The different kinds of interactions you're going to have
And honestly like this article just by itself
Kind of deserves to be an entire video. I'll leave a link down below if you want to properly read it
But of course not everyone is in favor of the Rust stuff
If there's someone like Ted so who is saying stuff like this publicly
There are other people that are going to have issues as well
One of them that leaner highlighted is this post from Jason Gunthorpe
If the ship has already sailed then we really need someone like Linus and co stand up and clearly say those words to everyone
And repeated a few times. I think there is a sizable contingent that does not believe that to be the case
And Ted's remarks of effectively wanting nothing to do with Rust are not unique or unreasonable
Given the cloudy situation. I know enough people betting on the failure of this experiment
In my honest opinion the current situation of Rust does not look like success
It is basically unusable except for unmerged toy projects
And it's still not obvious when that will change
Can rely on Red Hat 10 kernel having full baseline Rust support?
If yes, then in four years, maybe the service such enterprise industry could actually take Rust seriously
Can Rust even support the oot back porting stuff? Everyone does is there a strong enough preprocessor?
What is the situation with android can an android device vendor write a driver in Rust today?
I've pondered if I should consider Rust for some of the greenfield projects i've done recently
io mmu fd in Rust generic pt
But at the end of the day that work is being paid for by people who intend to backport it to old kernels
I can't write it in Rust and meet that need. I bet a lot of people are in the same boat
the reason why Lina got annoyed with this is um
One of those toy projects that he was talking about was her gpu driver, which
Is not a toy project. It's very far from that
Now he did slightly change his wording here to say yes
agx really cool project amazing software
But it doesn't change the fact that agx is unmerged and serves a tiny niche user base with no commercial relevance
That is an unmerged toy by my definition
lina again disagrees here wherever you can find her comment because
Tons of people commented here
There are a lot of people who are interested in what work she is doing
There is a lot of commercial interest here
It's just not the same people who are interested in what RHEL is doing
This thread has basically all of the faces here. We have a keys cook a prolific kernel developer
We have jonathan corbet who is the maintainer of l w n
We have a bunch of other people like Joshua Ashton, Dave Airlie, Neal Gompa
Because Neal is everywhere as i've established before like if you want to just see
basically a bit of everything here
Again, I can't read the entire thread here. It's just way too big and as he tends to do
Drew DeVault also had i'm not going to say
A take on this because for about three days. It was the only thing he was talking about
Basically posting every hour or so a motivated group of Rust developers could build a production ready
Mostly Linux compatible kernel from scratch within five years without doing any politics on lkml
Passionate three to four person hobby os's have achieved impressive levels of Linux compatibility
Very quickly pour the level of enthusiasm the Rust in Linux has into a greenfield project to build a Linux compatible kernel
And you would have astonishing gains very quickly
I think there needs to be some time to heal
But the Rust in Linux folks should really rally around a new Linux compatible kernel project from scratch
It'd be wild it would actually work whereas Rust in Linux is still a huge gamble and a burnout machine
Rust would be a really good fit for a big Linux style monolithic kernel
And they could realize a lot of gains very very quickly in my opinion
Not a great fit when retrofitted into the Linux establishment up until that point keeping things pretty tame
And then as drew tends to do one person ticks him off and then he goes on a psycho rant
And he also wrote a blog post about this pretty much saying a lot of the same stuff he said in
His many many many tweet threads
There is just one part I do want to highlight in here though
Rust is a great fit for a large monolithic kernel design like Linux
Imagine having the opportunity to implement something like dcache from scratch in Rust without engaging with the politics
That's something a small group of people
Perhaps as few as one could make substantial inroads on in a short period of time taking full advantage of what Rust has to offer
A lot of people on the Rust side are not saying his name
But it's very obvious who they're talking about when they say oh some big Linux name
So big Linux blogger is talking about how Rust people should go and make their own kernel and not be involved in Linux
I understand why they're annoyed by this take because what he's effectively saying is
Don't get involved in the kernel that people are actually using go and make some
Educational project go and make some toy project that nobody actually cares to use
Maybe if you encourage some big company to work on it with you, it'll get some adoption
but
Going and trying to make your own kernel is not going to have any real adoption for a very very long time
Redox is a great example of this redox is a great project, but it's very much still an
educational, experimental project
This is not a situation that's going to end
Tomorrow in a couple of days in a couple of weeks a couple of months
This is something that is going to have to be dealt with
If people actually want Rust to be in the kernel now. I do like Rust
I think having Rust in the kernel is going to be beneficial. I just want to make that clear, but
You can't just go ahead and keep being in this situation where
A lot of the maintainers some of the maintainers very big maintainers will say
Don't want it to be here. These problems have to be sorted out because it's only going to get worse from here
So far to the best of my knowledge Linus Torvalds hasn't yet made a statement on the situation
I'd be very surprised if there weren't some behind closed doors discussions
I don't know if he's going to make an official statement
If he's just going to talk about random things on Linux kernel mailing list
If he does say something an absolutely go to talk about the response as well
Linus is the BDFL. He agreed to bring Rust into the kernel
He now has to accept the fact that he has to deal with this problem
Is he going to take it out of the kernel? Is he going to tell people to fall in line and deal with it?
I don't know what his response is going to be, but I feel like he really needs to say something
Now someone who did say something is Wedson the guy who retired from the Rust for Linux project in a comment to the register
When I started on this project, I fully expected we would get pushback on technical grounds
And I was willing to work under that assumption that eventually we would find consensus
Almost four years into this I expected we would be past tantrums for respected members of the Linux kernel community
I just ran out of steam to deal with them as I said in my email
If it isn't obvious the gentleman yelling in the mic that I won't force them to learn Rust is Ted Ts'o
But there are others this is just one example that is recorded and readily available
I've heard in the past from several maintainers that they're just overburdened and don't have time for anything else
I'm sympathetic to their plight those who can't or don't want to be involved are obviously welcome to stay away
This does not and did not bother me at all
The team has been setting the groundwork for new components such drives be written in Rust
But as these are developed we're running into some roadblocks
Torvalds doesn't seem to care or perhaps believes they are appropriate time will tell
Ultimately, I don't know how this is going to play out
If you want to know my opinion here
I think that the Rust people
Are making a good point. I do think this is going to be a lot of work to make it work
But I think in the long run
Having these Rust bindings here having this encoded into the actual function signature
Having this be something that is just accepted in the kernel
Is probably going to be a good thing. It's not going to be without work
It's not going to be without a lot of work
But in the long run if they don't do it. I don't know what's going to happen
But let me know your thoughts down below if you liked the video go like the video
And if you really liked the video and you want to become a one over these amazing people over here
Check out the Patreon, SubscribeStar, Liberpay linked in the description
Down below that's going to be it for me and
Give me all of your programming language wars in the description the comments because I know you're going to do so
Anyway, I don't even need to prompt you for it