long long ago in the ancient times of
2021 we saw the first attempt at
bringing Russ support into the Kel 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
for Upstream it wasn't even ready for an
RFC this shouldn't have been anywhere
near the Linux kernel because Russ's
biggest benefit is all of the whole
memory safety stuff oversea 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 Kel level it's fine in user space
but the kerer was a different Beast with
the main point of 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 10 different
versions of the patch set center of the
colonel all trying to get reviewed all
trying to get merged all getting a lot
of feedback before finally being ready
to merge in the 6.1 window but this was
still very early days what existed at
the time was effectively the Hallow
World version of this infrastructure it
was not ready for full-on drivers yet
that was still going to 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
lonus tvols did accept the merger into
the Linux konel and at the end of the
day his word is
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 being 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 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 Russell Linux project
this is as short a series as one can be
just removing myself as maintainer of
the rust for Linux project I am retiring
from the project after almost 4 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 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 a spelling mistake there I
didn't spot that one before I wish all
the success to the project I truly
believe the future of Colonels is with
memory safe languages I am no Visionary
but if Linux doesn't internalize this
I'm afraid some other Colonel would do
it what it did to Unix lastly I'll leave
a small 3 minute 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 not trying to reforce
new ways of of specific ways of doing
things we're encoding how things are
done in the IAT lock example
here right
this is early days we're not trying to
boil the ocean here yeah we're almost
out of time here and I I this is who
you're listening to is uh Ted so who is
a very prolific colel 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 Pro
promulgated by rust and the reality is
that ain't going to 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 the 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 Bings
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 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 fil as I said they're like let
me talk let me just respond to what
you're saying systems that disr depend
upon is like not a
okay so like we'll see I I I suspect the
best thing to do is you to continue
maintaining your rust bindings over time
there will be continued code refactoring
right maybe we will start using you know
uh our uh Kree 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 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 t let me try to to respond
to that I'm not saying that c is going
to be uh stuck in whatever it has it's
not what I'm saying I actually what I'm
trying to say is I want to to for you
guys to tell me what the semantics are
of these things that will reflect in
Rust that's that's all I'm
saying no but the fragility from my
point of view is 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 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
wild rest is a second class citizen I'm
fine for you guys to say we we don't
care about this uh uh you guys 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 I'm not going to fix rust
bindings sorry t 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 poly to see if you
guys could give us semantic information
that's that's all I'm asking you 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 sea
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 Russ perspective
they want to have the semantic
information of how these function 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 got to examine the source code to
know things like does this function
accept a null does it accept 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 seide they
don't want to have to deal with rust
because well they're SE 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 heeded 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 a 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 mastedon not
going and like talking about people
without really thinking about their
perspective not straw maning 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 of statements that
various people involved have put out the
first one being from assah Lena a subset
of SE internal 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 1 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 pointed out that other C
drivers also trigger the same but
because the API is just bad and
unintuitive and there are many secret
hidden life requirements he wouldn't
budge one SE driver works so rust
drivers must work the same way next we
have Jeremy Soler of system 76 a big
engineer in the cosic project and also
the lead developer of Redux OS a system
entirely built around rust rust
applications rust desktop rust kernel
everything is rust this kind of
treatment is exactly why I started Redux
from scratch and ridden 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 internel anymore
there are projects where you inevitably
have to get changes past patronizing
pedantic megal maniacs and while the
Linux kernel is not only developed by
this personality type it is
overwhelmingly controlled by it I have
no fun memories of submitting patches
there whereas I find contributing to
most Russ projects to be downright quite
delightful next is lud poool an exog
Foundation board member Mesa whand and
Upstream Linux Colonel developer okay
actually serious post about Russ phinix
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
colonel 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 DRM either I should specify DRM
when we're talking about the Linux
kernel is direct rendering manager not
digital Rights Management while I think
DRM is honestly kind of really on top of
a lot of stuff in ways I wish the rest
of the colel was but like it's not like
I'm going into other colel 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 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
of 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 case 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 Carol herbs a Mesa and noo
developer maybe at some point I should
talk about some of the push back I've
gotten when I propose rustical to be
merged into Mesa but all in all I think
we can safely say that introducing Russ
to Mesa as a success I don't know how
much that impacted Faith extran riding
Knack 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 Davey wrote an
entire blog post about the different
kinds of people you run into in the Cel
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 it 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 tedo who is
saying stuff like this publicly there
are other people that are going to have
issues as well one of them that Lena
highlighted is this post from Jason
gunthorp if the ship has already sailed
then we really need someone like lonus
and Co to stand up and clearly say those
words to everyone and repeat it 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 we rely on red hat 10 kernel
having full Baseline rust support if yes
then in 4 years maybe the serice 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 mm ufd 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
Colonels 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 Lena 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 Lena 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 re is doing this
thread has basically all of the faces
here we have keys cook a prolific Kel
developer we have Jonathan corbette who
is the maintainer of lwn we have a bunch
of other people like Joshua Ashton Dave
ay Neil gumper because Neil's 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 Dev Vault also had I'm
not going to say a take on this because
for about 3 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 Kel from
scratch within 5 years without doing any
Politics on lkml passionate 3 to four
person hobby os's have achieved
impressive levels of Linux compatibility
very quickly poor 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 Ross would be a really
good fit for a big Linux style
monolithic Kel 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 Colonel design like Linux
imagine having the opportunity to
implement something like dcash 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
o some big Linux name some big Linux
blogger is talking about how rust people
should go and make their own Kel 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 is not going to have any real
adoption for a very very long time Redux
is a great example of this Redux 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 colel now I do like rust I
think having rust in the konel is going
to be beneficial I just want to make
that clear but you can't just go ahead
and keep being in the 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 my knowledge lonus to
volt hasn't yet made a statement on the
situation I'd be very surprised if they
w 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 colel
meting list if he does say something I'm
absolutely going to talk about the
response as well lonus is the bdfl he
agreed to bring rust into the colonel he
now has to accept the fact that he has
to deal with this problem is he going to
take it out of the colonel 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 Russ filin project in a
comment to the register when I started
on this project I fully expected we
would get push back on technical grounds
and I was willing to work under that
assumption that eventually we would find
consensus almost 4 years into this I
expected we would be past tensions from
respected members of the Linux Kel
Community I just ran out of seam 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 so 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 over burden 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 opponents
that drives to be written in Rust but as
these are developed we're running into
some roadblocks TVs 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 Russ 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
binding 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 like the video go like
the video and if you really like the
video and you want to become one of
these amazing people over here check out
the p patreon scribes Liber pay 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
descript in the comments cuz I know
you're going to do so anyway I don't
even need to prompt you for it
[Music]
something like this