So, welcome back. We're going to continue with the next keynote in this case is Rathful Linux.
And for that, we have a very, very nice person to talk about it because it's the maintainer of the Rathful Linux subsystem.
So please welcome Miguel Ojeda.
Hello everyone.
Thank you.
I'm honored to be here. Thank you to the organisers for inviting me.
Normally, for the rest of the new stocks, I give, I start to update or I give some details about what we are doing.
Since that the team is working on and so on, but for this keynote, I thought it could be a good idea or an opportunity to do something slightly different.
Do you see what I mean when we go through a talk?
I will start with a brief context for those of you that may not know about the project yet or or or may not have heard about it.
And then I will continue with walking due to the history of the project to give you a different perspective of,
to understand the project where the how we got into the place we are now.
And it's just a different way of looking at things. So let's start with a context.
So what is Rathful Linux? This will be very brief.
Rathful Linux is a project that will be in Rathful Port to the,
Support for the Rath's language, sorry, to the Linux kernel.
This is where the fairly,
Generally because on purpose because it's not, you know, about bringing Rath's into drivers only or to modules only.
It's not just about maintaining and out of three fork.
It's not about loadable modules.
It's really about having first class support for Rath's in the kernel.
But upstream in the afternoon kernel in may line.
It means the long-term goal is that if you are a kernel developer or a kernel container,
you can choose where you, what do you pick, see in our days you can choose Rath's in the future.
So that's the goal.
Very quickly, who uses it?
Well, currently in entry means in Linux is a tree.
So in upstream in the kernel, we already have a few drivers or small modules.
Sorry.
I should not move.
But we also have major users.
Currently outside of the kernel that are trying to get upstream and finishing up.
Streaming the dependencies and everything they need to, to finally,
within the driver, because it has to be done in step by step.
So you first have to upstream the dependencies and then you're upstream the driver.
So for example, we have there in the list Android binder, which is successful,
and eventually goes into Android phones.
It means that millions and millions and millions of people will be using it in all Android phones.
We also have Apple, GPU driver, the NVMe driver, and the, well, a few months ago,
the Nova, GPU driver for Nvidia was announced.
And many other efforts, as well, in different places that people are working on.
Now, of course, the question is, why we are doing this to being in with, right?
Why we want to put a second language into the kernel, because it has a major cost.
And we recognize it has a major cost.
Introducing a second language is something that we have since the very beginning.
It has a big cost for everybody in the kernel.
And in the kernel, as you probably know, has thousands of developers, hundreds of companies,
who are recycled, working.
So, yeah, having everybody agree on what we are going to do, how we are going to do it,
the guidelines even for a new language, et cetera, is a big cost.
So why we are doing it, and especially why we were picking rust, right?
Why we are picking rust?
So you have heard, I'm pretty sure, about memory safety, especially in the last year,
we thought this talk about potential regulations, you know,
things like that.
I'm not going to board you with those details.
But instead, for those of you that have done see, but you have not done rust,
and maybe you are unconvinced, I don't know why we are doing this.
I am going to just give you an example to pick your curiosity, a very simple example to pick your curiosity,
and try to give you the reason why we are doing this.
So, we have this function in see, right?
Please take a look for a few seconds.
And if you, if we assume that the requirements for the function, the requirements for our,
our function are the comments or the documentation on top of the function,
then who would say, I'm pleased with your hand, who would say this is a correct function?
Okay, who would say is incorrect, or that is has a bag, because it doesn't comply with the
specification, all right?
Okay, some of you may be thinking, well, maybe it's not correct,
because I should be checking for an adult thing like that.
Well, since the specification doesn't say anything about an adult, let's put it aside as both
correct in both cases, okay, well, which I cannot.
So, well, here, of course, that you see the bag is obvious, right?
So, the function doesn't comply with the specification.
So, what about this one in the bottom?
It's the same requirement.
I only change the constant.
So, what do you think about that one?
So, please raise your hand if you think that one is incorrect.
Again, ignoring the checking for an adult.
Oh, so some, okay, so some hands, okay.
So, who thinks this one is correct, finally?
Right?
So, some people don't think this one is correct.
Okay, good interest in maybe to discuss.
Let's assume this one complies with the requirements, okay.
Let's assume this is correct.
This is a correct function is something that a C programming may write in their code ways.
So, you will move these two functions into a grid.
Okay, and in the y-axis, we have incorrect at the top, correct at the bottom.
All right.
Now, this is how you would write the same functions in rest.
All right, so one way of writing them, but the equivalent, let's say,
and I'm always exemplifying.
I'm going to oversimplify in this slide, but the way you would write the function
would be something like this.
Those functions look similar, right?
It's syntax wise.
I mean, it's something that takes the same effort to write, right?
The syntax, the tokens are a bit different, but that's minor details.
The both functions, the incorrect ones and the correct ones,
the both sets of functions, compile to exactly the same thing.
Okay, so where did you compile with this?
You see your plan, the same instructions will come out.
So, well, you could say, well, then what is the point, right?
Now, the point is that the functions on the right side are what we call safe.
And there is two minutes here of safe, and the point of this right hand side functions,
even if they compile to exactly the same binary or the same instructions.
The point is that as an implementer of the function, when I wrote the line,
that expression, you know, access in A and access in B, and then the quality operator,
I know I have not introduced any family heavier with a line.
Okay, so as an implementer, I know there is no any family heavier that can trigger here.
Any family heavier for those that may not know is the kind of thing that, you know,
it's a memory safety issue, you can trigger vulnerabilities with it.
Naysal demands, you know, coraggio memory, et cetera.
So, very bad.
So, then that's one thing.
And the other thing that you get with the right hand side version is that the collar,
as a collar of the function, not implementer, but the collar of the function.
I know that I cannot introduce any family heavier either, when I call this function with any input.
Right?
And again, I am over-fimplifying, I am not going to go into the, you know, details of when that holds exactly.
But I will show you the rest version of the left hand side.
Okay?
This is the left hand side.
This is how you are writing rest.
The same version as the, as I see one.
Again, all these at the top and all these at the bottom compile to exactly the same thing.
You see there are two colors.
That's the meaning of the two of safe safety things that I mentioned.
One is that I don't introduce any family heavier as an implementer and the other is, I don't introduce.
And the family heavier as a collar.
And when you think about it about the and the family heavier.
The thing is, well, you may say, oh, you know, writing T is maybe, yeah, it's pretty obvious that they're,
the incorrect one there in C is incorrect, right?
But the thing is, when you scale writing code in the right hand side, when you scale T is two type programs,
no in that you can just know that there is no and if I'm here with that one in the right hand side is very powerful.
Especially as the program, as the program gets more complex, that is a review for power two properties that we get out of that.
And moreover, when you consider the lifetime of the project, right?
When you consider maintenance, when you consider all the changes that are going into a project over time,
the risk of making a mistake.
For example, the risk of making a mistake when you pass a pointer to the C1 or the rest one in the left hand side,
or the risk of, you know, making a bag on the left hand side that introduces and if I behave in the implementation of the function, that's also a big risk.
And therefore that's why, and that's the main reason why we want Rust in the kernel to write the code like in the right hand side.
Now, of course, if C would have, if I had a way to write that same thing in C, so that thing that is missing there,
we would love to do that as well in the kernel, and I imagine in almost every single project.
At least that's what I think we should do.
The thing is C does, and currently have a way to write that, and neither does C++, and neither does CG.
So that's why we picked Rust in particular, right?
And I hope this example, this very trivial example, just pick your curiosity, if you have a seat developer,
and you see this concept of, or this or tonality of safety and correctness.
And again, I know it's simply fine here, but that's the point, you can have incorrect or correct code,
and you can have safe code, and safe code, and all variations.
So for example, you have, for example, you have, you know, you call memory copy, like this.
It's the same thing, right?
And if you know, you have a perfect program in C, the program is still unsafe.
Because even if it is perfect, you don't get those properties.
Even if it is perfect, you don't get those properties with a C code or the unsafe version of Rust.
So that's the key point I wanted to mention.
And of course we have, and of course we have other reasons why we picked Rust.
This is, this goals slide is from the original Rust for Linux.
And we mentioned other things, it's not just memory safety.
We also mentioned that we believe it's going to reduce the logic, the number of logic bugs in the kernel as well.
We say, we talk about documentation, we talk about maintenance, about modules being becoming easier to write.
Okay, so there's other reasons not all.
Of course memory safety is the big one, but there are other reasons as well.
And this was a year ago in 2021.
So now let's talk about the history.
This is the second part.
Let's talk about the history on first.
I'm going to go through the pre-history.
History before Rust for Linux.
So you have a bit more context on what happened.
First, the first thing for the first project I'm aware of.
That played with the idea of ALSU Rust for the kernel is TysoKins.
And sorry, if I meet pronounce Rust.ko project in GitHub.
That is the earliest I could find.
That was even before Rust 1.0.
Many, many years ago.
More than 10 years ago.
Of course it was very simple.
Different syntax even in Rust, but it was there.
Then years later, an important one, because we used it as a base for the code that we had in Rust for Linux, was Alex Aguinole and Jeffrey Thomas.
Fishing about Linux kernel module Rust repository.
There they play with the concept of the starting to write abstractions, which is what we call to the code that you know.
encapsulates the safety of the CLPIs and other things in the kernel and provides us safe API to the call for example drivers.
So they started doing that.
But note that both of these approaches and others are probably worth it.
And I mentioned and at least one more that they know about.
They are all out of three approaches.
They were not trying to integrate Rust into the kernel.
They were not trying to play with building code.
They were not trying to upstream.
They were not trying to share, for example, the standard library across all the modules.
So it's module, for example, was quite big.
Now, a year, the next year, Alex and Jeffrey presented in the Linux security summit their work.
They said, talk about that.
You can watch.
And also around that year, more or less, this is not really a precise line, the red one.
At some point, GitHub doesn't have created the organization back then, but we didn't really use it.
That was nothing, there was no activity that year.
And now we are going to shift the timeline to the right.
And we are going to...
Let me check, sorry, then.
We are going to the next part.
Now it's 2020.
And in the next summer, so in the summer of 2020, at some point in Nicklesonia, from Google, we were talking in private.
I was talking with him in private.
We were setting some ideas a few of us.
And at some point, Nicklesonia and email to the main list, and said,
Well, what about the rest in the kernel and so on?
What can we do our LPC talk?
And T-strigger are going to LPC.
So we went Alex, Jeffrey, your three-plet,
Jamboblitz, your three-plet, Alex, Jeffrey,
Nick and myself, sorry.
And we went to give the varies in two and three kernel rest in the kernel.
So that was the first LPC talk.
It was a pipe dream for everybody.
Nobody was thinking, oh, this could actually happen.
We were still thinking.
But I saw that there was enough people, you know, interested,
and playing with it outside, out of three.
That I took a few, I think was days one week, something like that, after the talk.
And I took my prototypes that I had for interacting with a build system.
And I put the first PR into the organization.
We had.
I ping everybody, and that was the first thing that kickleball, probably.
After that, people started to join.
I was hopeful that people would join the project.
And in fact, they joined Adam Fiona, joined the project very, very recently.
And then we will see others from the court team.
So soon after few months after we did a main list,
we requested a main list in kernel.org for us for Linux.
Then we, this is something that people sometimes don't know.
In Linux, I requested a branch in Linux, because we were confident.
We were doing this was, you know, something that we don't could actually upstream.
At that point.
So we submitted the branch to Linux next.
So the code, or at least part of the code that we had,
has been in the integration branch of the kernel for that long.
Right, even before that of C.
Then we submitted an IFC, which is the one I link before in the other slide,
where we talk about why we want to do this.
Where are the reasons behind RAS, etc.
Then soon after we created a solip.
Sorry, we created a solip.
The reason is that we used GitHub and solip because RAS was using GitHub and solip,
and we needed to cross, you know,
crosslink issues, crosslink stuff.
So we did that.
And solip was something that RAS developers were, had the experience with.
And they were accustomed to that.
So we used that the same thing.
And solip has been a really nice solution so far.
So we are also sponsored by the solip company,
the sponsor of our solips.
So that was great.
We are very happy with it.
Then after a while, we have the first maintainer summit,
and the first cangrejos.
Cangrejos is a RAS for Linux conference.
So for example, if you are thinking of doing something like this,
now the project, I'm trying to bring RAS to another project.
The things I mentioned here, like,
cangrejos, like the integration,
perhaps the main list.
What you are going to see is that I am adding things,
and we are adding things to try to bring people together.
So the conference idea was something,
it was online.
The first year was online.
But it allowed us to set up everything.
And then people have been coming to Cangrejos
to the RAS for Linux conference every year since.
Then we met in Cangrejos.
It was online because it was COVID and so on.
And then we had the first maintainer summit.
We were invited to the maintainer summit in the kernel
to discuss RAS, the possibility of RAS.
And this was, again, online as well.
Then months pass, and we have several versions there.
As you see, the version 5 version 10.
We also, another thing is, in the PC,
there are micro-conferences.
So we also ask, hey, or we were told.
In fact, I think we were invited to have a micro-conference
across RAS for Linux in general.
So we did that as well.
And then we submitted, it's an after, the maintainer summit
because that time was the PC, the time of version 10.
That was the PC as well.
That year, we had a maintainer summit as well.
That's the maintainer summit where Linux ask everybody in the room.
What do we do about RAS?
We try to experiment with RAS.
So we allow the RAS experiment to go in entry to get merged.
Nobody really complained at that moment.
So we went ahead and Linux took the code and merged.
Then we added other things like, you know, we started our webpage later,
where we put everything that is related to, you know,
it's like a half of links.
If you want to contribute, for example, that's a web you go.
And if you read our webpage, you have all the content that you need.
And it allows us to update the documentation that is hard at the top date in the kernel.
We also, as you see in the top later, we have RAS docs kernel.org.
That is the generated documentation he rast put in the kernel.org domain.
Another thing that happened.
Now, I want to focus the next few slides on the other three points here.
The RAS CI, the increased collaboration with upstream RAS,
and the first minimum RAS support to version.
So since February that year, the 2024, we had regular meetings.
We increased the collaboration.
We already collaborated, but it increased the collaboration with upstream RAS.
Because we needed it as you probably know, and stable features.
Which are features that are only nicely compiled, supposedly.
So we wanted to fix that and make it stable.
We were using, since almost the beginning, we are using stable releases of RAS.
But we were solving the problem of the unstable features by pinning the version.
We only supporting one version.
Now, we jump to the next fixing everything in between.
And that's it.
It was a reference, it was a flagship RAS project.
And it's going to become another flagship RAS project goal for the next half year.
So now.
But one thing, and this was the bigger thing that we got.
And it was the first and the fastest that we got, is that the kernel is now,
or since then, is in the RAS upstream RAS, in the compiler CI.
So it means every PR that is merged into the RAS builds the kernel,
a very simple configuration, but it builds the kernel, and it has to pass.
So that way, we were trying to edge against changes in an unstable feature,
especially in the language.
So that was extremely good.
And it allows us to unpin the version.
So before we could only use one version.
Now we could start supporting the first time, for the first time,
I'm MSRV, the first minimum support is RAS version.
So we did that just that.
And it was something that Linux requested, and I think it's quite important.
And because we unpin the version, then we could start supporting distributions.
So you see it's like a train of things.
We started supporting distributions.
And now we have support, generally, of those distributions.
Things can break at some point.
Still things are not completely fixed, but these are the distributions,
and others that probably works on them.
So you can just install, put the commands that we recommend, and it's a work.
So we are back to the timeline.
And here, very quickly, I give you a few more data points or time points of what versions,
where of what versions of RAS were available at which time, and the Linux versions LTS.
We are in LTS, and we support RAS there.
I mean, there is almost no code in, for example, in 6.1.
There is almost no code, but we keep it compiling, and we keep it building.
6.12 LTS is the first one, where the opinion is there.
So if you see 6.12, it's the first version that we will support a range of compiling versions.
Now, I think in our projects that grow, I think it's important to give a list a quick mention of who is the team.
So I replace the bottom part of the timeline, and I put where people join.
These are the people of quarter, where I say that Adam Fiona others that joined the project and collaborated.
They were much, there is a lot of people that collaborated.
But these are the people in the court team, and when they roughly joined.
And I will mention a few words about them.
I think it's important to have a good team.
And really, the people that joined, even since the beginning, they were very, very good.
For example, Watson was the arena author of the Android binder driver, the 9 piece server, the NVMe driver.
Other things.
So he was like, what I call a research in the year, in the sense that he was playing with all the toys that we had,
and tried to make things that would show that the rest in the kernel was possible and how it could work with the features that language had.
As you know, with some left, but he has been a pleasure working with him.
And I wish he was still working in, in restful years.
Then we have Watson.
I will not read everything.
But Watson currently works on the cork kernel, RCU, his or her, or the memory model.
And things like that.
John is, I think it's well known in the RAS community, in the RAS compiler, in particular,
he maintains the crane lift back end.
And we, he's not that available anymore because he has a full-time job, but he's very good.
He essentially, when we have a question about RAS, we just go ask him about what we, what we need.
Now we have Gary.
Gary, it's a very versatile.
He, I think, is his or her part of the RAS project.
He's very versatile.
He knows about all kinds of stuff, you know, low level embedded,
SPAs, I think, so yeah.
It's another person we go through to ask any kind of low level stuff.
Then Beno, Beno is, again, I will not read, but I will just give you,
because we're in a university right, and this, I think, is quite important for how to collaborate.
Beno, if you read it, Beno, didn't really, as far as I understand, didn't know much RAS,
but within a year, something like that, I don't know how he did it, but within a year, he learned RAS,
and then he started to learn about the kernel, and he contributed.
And he solved, actually, a major problem we had in the kernel, the opinion it,
solution that he provided, to, to, to, you know, to, to, to, to ease how we,
we write and to remove unsafe coding in some parts of the abstractions that we need.
And then he is working on other things, but including a, a major language feature for us.
The key thing I want to highlight here is that Beno is the primary example of, hey,
if you are a student, you are learning, you, or not a student, but you are learning,
you want to contribute, you can just contribute. He joined, and then he's now part of the core team.
And I think you can do that with RAS for the new RAS for the new RAS project, he just need to start.
And RAS, and RAS, work in, originally, at Western Italy, and, and then, at Samsung,
he has been fighting the, hardest, I think, he has had, sorry, the, the hardest fight in the kernel,
because the, the project that he took, which is the envy of the RAS and, and, and,
and the, and the abstraction that he needs, require, to talk to maintainer that,
where not, or are not, really, a pro-RAS.
Then, Rafael is, Alice is also very well known in the, in the, in the RAS community.
He's usually our experts on, on RAS stuff, we, we go, to her on, on, on language, since.
He was a Google, and, and he's, continuing, the, the, the, the, the, the, the, the, the,
the, the Western started, like, Andreas is continuing the envy of the river that, that, that, that,
it started, so, uh, yeah, Alice is, uh, like the others, it's, yeah, they are all incredible.
Travor, I picked the, commit message, um, when Travor joined,
this is the commit message in the kernel. Uh, Travor's part of the RAS community,
he also does the working, and he maintains the, in the kernel,
maintains, uh, two fighters, uh, on his part of several teams and so on, so, yeah,
I know the very talented person and finally we have Daniel O'Witch, who
has done literally a few days ago, was made official. Daniel O'Witch, the
maintainer of the Alok API in the kernel, the rest of the API, and he is leading the
nova driver, that I mentioned before. So I want to give, let me, I want to give
a very quick mention about DCC, especially because we have a phosem. So I think it's
very important for DCC to get into the train of rest. I know that is the front end,
that is the back end, there are several ways to use DCC, even other ways that could be in
the future, like the C-back end. But what I want to emphasize is that I think DCC as a community
as a project, should support these projects or these people behind these projects as
much as possible. There is people in the kernel that you will see, want to compile the kernel
with DCC, they don't want to use LVM plan. So we need a solution for DCC and these solutions
actually are quite well advanced, but I would, I am making a call here to please come
talk to me or them if you want to support them with DCC because they need to support. I am
going to give you very quickly to timelines for DCC for both projects. This is from
Mantany, he gave me the lead of the project, he gave me the timeline of the rest C-code
and DCC, how it happened and as you can see there for quite some time, it can compile and
build for Linux. So it can compile the kernel. So we have a solution already, it's experimental,
but it has a solution, we have a solution that it already works to sound degree, at least.
We need more support to make it this reality and make it an option to compile the kernel for real
with DCC. Then we have the other approach which is DCCRS, DCCRS is a new front end for us in DCC,
rather than a back end in RSI. Here you have the timeline and I will summarize saying that
they hope to compile the core library of rest and modify it as far as I know in DCC 15.1.
This may I think, in the release of DCC 15.1, that's also big news. From there to compiling the kernel,
well the gap is still big, but there is a very real processor. Now this is the second part of the
big second part of the talk. It's a bit of a surprise. I wanted to take the opportunity in this keynote
to give you again a different perspective of the project. So what I did is I sent a lot of emails
to kernel people to see what they think about the rest in the kernel. I emailed, as I said,
a lot of 150 people, I got many replies, a 20% of the emails I sent were container reply.
I want to say that the results may be biased because I try to contact people that were relevant to
rest in the sense that we talked about rest, well, positively or not, in the kernel community.
So I contacted people that were both positive and negative about rest, but most of them,
because most of the kernel containers we talked with are positive or neutral, so there may be some
bias on the response. I want to thank, of course, everybody has replied because it's a quite unique
collection or compilation of replies. One more thing, I gave the opportunity to everybody that
replied to a stay anonymous, and I am presenting every reply. I cannot go through all of them because
there are too many, but I am presenting all of them. You have here all of them. So let's get started.
Of course, all mistakes, and everything else, the bolding I did in the slides are my.
So first I'm going to start with Daniel, because there is no, the codes are not in any given order.
Okay, there is no order in the in the codes, but I picked this one first, because there was a big
timeline related thing at the top, the first sentence. So 2021, if I will be the year of
rest, computer drivers. Well, this is a bold statement, and it's a very direct, so I wanted to highlight it.
Here also says, engineers from multiple companies are joining together, and given all the
by in from containers companies and engineers, I would say rest the rest is definitely here to stay
in this part of the kernel. So Daniel of course, very positive for all of it. He's in contact with
a thesis companies and engineers, et cetera, and I think he's right at this year or at least maybe
the next will be the time for for GPU drivers in rest.
Then we have Paolo, Paolo is a maintainer, and I cannot present a divided story, but very quickly
you will recognize names, and if you work in the kernel you will recognize, and if you don't work in
kernel you will see other names that you probably recognize. So Paolo works as a kind of maintainer as well
in many not just in the kernel, but also in QMO and this is I think. And he said that the challenge
of writing correct, an idiomatic bindings is not trivial, which I agree.
Paolo is a six-rowing, that is possible, and I'm sure that all the projects will follow.
So Paolo is also positive. As you see in the top, I keep, because I send emails with some
questions on topics, some people decided to write a overall quote, another reply to each question,
so I highlight that in this case. And I really told me that one of the most exciting developments
elements, that the potential to attract a new generation, he talks about the potential to attract
a new generation of developers, and this is something important, it's something that since the beginning
as I said we wanted to do, we wanted to rest to attract new people into the kernel, but he acknowledges
that any big change takes time. And we have Derek, he says at the bottom the project needs to be careful
to not overload the containers and distribute the increasing workload to more shoulders.
This is something that we think is very important and it's very true. And we never said
we are going to maintain every single part of the rest as sections in all the kernel.
What we said is we need the help we need to scale things across containers. We need the
maintainers help to succeed here. This is something that we said in the very first maintainers
summit in person about the rest for leaders, and it's important to highlight that.
Carlos Ibao says rusts, because weaknesses as a language is a relatively few people speak it.
It's true, I agree, that's the main problem right now that the maintainers, I think the main
problem is that the maintainers don't know rust, and they don't have the time to learn rust
in some cases. If they knew rust, they could probably use it as they, some of them say in the slides.
Fiona, if you want to contribute to rough renews, I say since very, very early,
use a space rust is helpful, but also not too much when using both a custom log and no
study. It means I think that if you do use a space rust, it's useful of course, but you need
more, at least to in my opinion, here, at least to write as sections. She makes a point about the
C-function, C-function is often lacking documentation, this is something that has happened many cases,
that kernel developers don't want to work in rust. They need to go to to read the
implementation, because there is no strong documentation or precise documentation, so we need to go
into the C-side of the kernel and figure out how things are going to make safe interactions for those.
Then we have Stephen, who is a criminal trainer, he says in particular the obvious,
speaking about whether rust could be used for kernel development, he says the obvious one is
memory safety, the memory safety gives, and that's really the downfall of C. I think that's quite
a strong call, but it's pretty nice. He thinks that rust will continue growing in the kernel,
but that he requires thinking differently. If we had a subset of C, that would be nice to use,
and it would make perhaps rust obsolete. His company uses it, but there is a code code,
it's not yet a candidate, for us code. He talks about, again, young developers,
at least again, a point that a lot of people also bring up. Then we have Kent,
sorry, we have Kent. Kent has given me quite a few interesting points, I will highlight too.
One is this one, so he says C and even more so kernel C have an enormous learning curve,
and he says rust helps that with that. So instead of thinking, oh, rust is harder than C, or kernel C,
is the other way around, if I understand correctly what he is saying, it's better to deal with rust than kernel C.
So I thought that that point was quite interesting. And then this other one,
where I say what he can says is a wide open field, with lots of interesting technical
problems still to be solved and cool work waiting to be done. This is something that I agree with.
In the kernel, there is many things that are already done, that there is a lot of people that
have been working there for decades, and maybe young people say, oh, you know, everything is done,
I don't want to get into kernel development. We rust, we hope that is the opposite,
because you can take any part of the kernel, really. And start thinking, how do I rub these APIs?
How do I rub these Cs, Cs, Cs, Cs, C APIs into safe abstraction, and I provide a better API
for drivers and so on. So I think this is a very, very important point.
Then we have the June, who may also, a good point here in the first one, I will say,
be the others. He says, the June says, I think memory is 60, a more extractor design and programming,
which are encouraged and formed by the language, which will be beneficial for the kernel,
while also being an obstacle to adoption that is. I think that's, yeah, that's fair, completely fair.
He told me that he, he was just blabbering. I think that he knows, he's quite a smart,
knows a lot, so I don't think that's blabbering, but he told me, hey, please know that.
He also mentions that there is an uphill battle in the kernel, and long term gains are to be had.
Luis makes the point of GCC, so the what I said before Luis makes the point of,
hey, we need GCC support. For many maintainers, it's quite important, it is part.
Myra says that with more than 30 years of history, the kernel has deeply rooted values on the structure,
making it different, difficult to change its curves, and for us to succeed, it cannot be a second
class citizen. It must be a first class citizen, the goal is standard for developing new drivers.
This is exactly what the pretty was about. It was about making first class language in the kernel.
Hans talks about that he wants to, he would like to use rise if he has time for it, and he
made with device drivers. Warframe mentions that he has no bandwidth to learn it,
and no customer currently wants to pay him to learn a rest, which is again the bandwidth problem
which we have discussed already, but he thinks that rest will continue growing in the kernel,
and that is not going to be a revered or removed. He also makes a good point at the top.
The biggest problem I see is with reviewing a rest code. He says, I simply cannot review a
revered within rest, which is an interesting point for sure. And he says, I need assistance from someone
who is able to do that. I can assist with, then with my assistance specific knowledge,
this is something that we have already happened in the kernel. A RAS expert and a kernel expert
got together, even in the mailing list in public, and also in private, and they got ping-pong,
they were ping-pong in the ideas and learning from each other, and that was a, they were several
instances of that, already in the kernel, and it is very interesting. That approach, as he
suggests, for sure, works, and I agree with it. S.A. says that he tried to learn RAS, but he was
more complicated than he wanted, but nevertheless, he says that after an announcement that we did
in LPC, he plans to start using it in Daemon to make memory safer and attract more developers,
and he's optimistic about the future. Now, we have David. David, he makes, again, several
good points. I would like to highlight that maybe that he definitely loves to see, see, pick up more
60 memory sets of features. This is something I really didn't speak too much, but I agree with
Mantenes that say, as I said in the beginning of the talk, if we had, see, with memory safety features,
this would be very nice, and the other point that in the slide is everybody involved, we will
still need to make compromises, this is true, we will need flexibility from Mantenes, we will need
solutions to work with Mantenes of subsistence that do not have time, or they don't want to
RAS, et cetera, et cetera. He makes other points here that we don't have much time, so I will skip.
Now, we have an anonymous kind of Mantenes, they say any sufficiently complex RAS codebase is
largely unreadable without RAS analyzer. I think especially if you are new to RAS, that is
very true, they are neutral on whether you will continue growing. Sorry, they are neutral
that is true, but they think it will grow. They mentioned, like others that develop new features
in RAS, the kernel is requires more time fighting the compiler, but when you do, it actually takes
more less debugging time, it is actually more likely that you just have it correct.
They also make the point at the bottom that the project is unnecessarily controversial, and I agree,
we don't want drama, we never want it any controversies or anything, we are trying to avoid
them since the very beginning, until something that everybody can tell you. So, yeah, hopefully
less controversies will happen. Another anonymous kernel Mantenes, they described several
good points, they say the resistance from some systems over individual, it is expected, but that's okay.
They also say that time will resolve all these issues, and he quotes or he says that RAS guys don't
really know that they have already won, well, he or C is very kind, both Linux and RAC8 want to give
RAS the chance, that is a huge win, that, yeah, I agree. Then we have Arden, he says, I am a
strong supporter of RAS in the kernel, although I do worry that it will make it even more difficult
to make pervasive three wide changes, this is true, it's a fair point, integrating a RAS
create in that manner is going to create all kinds of challenges, I expect that's interesting because
we have discussed, third party creates how to support them in the kernel. We have Paul McKenney,
he says that RAS appears to be the new hotness in universities, which I hope is true.
He thinks there will be memories of issues in C and C++, let's hope for that, he says that
the patient and persistence has been good of the project, and will likely be required for going forward,
which I agree. We have Joseph, Joseph has a very strong point right in the beginning, he says,
I don't ever want to go back to seed based development again, and he mentions also that he has
been doing kernel development for 20 years, he maintains a fairly important part of the kernel,
so it was like a very strong statement when I saw it. He also says, RAS makes so many of the things
I think about when White and C are not issue. He also at the bottom says, I wish RAS were most
successful in the Linux kernel, and he will be eventually. Also Greg, with permission, I put the
I copied what he wrote in one of the PRs, the one of the recent PRs, that he sent to Linux.
He says, I think this is the tipping point, expect to see way more RAS drivers going forward now, that is
bindings are present. Tenjada Tan, Corbett, the Linux-related new editor, and also a kernel container.
He says, the RAS for Linux has already achieved an important goal,
proving that RAS disindeed a viable and desirable language for kernel development,
that we should never the less expect a fair amount more shouting, because this is the kernel,
and that he thinks this work is important for the long term viability of Linux, which I agree.
I think, at least within a decade, if Linux doesn't do RAS or something equivalent to RAS,
is true that we may start to see other projects, other kernel, trying to use a rango to
set it. And very quickly, what other stakeholders think is also take a look?
The other editor, one of the other editor, the rock, he says, on the Prami language side of things,
seen a fine type using the project on language has been interesting. I think he will be many years
until RAS is fully integrated, it's good to have this. RAS, which very well known in the RAS community,
of course, RAS for Linux has pushed RAS towards stabilizing feature that we will also be useful as well,
and it has also been a great challenge for RAS, as the kernel has quite a special needs.
Tyler, who leads a language team, call it, language team. RAS for Linux is a big deal for RAS,
he also says that he would like to see memory safety and interoff feature, since he
would be extremely positive direction for C.
John says that RAS is the point of this is his support again, and again, it's very fair.
I will skip some, sorry. Ding makes, I remember Ding and saying greatly,
Kindle, my interest in explain areas of the Linux kernel, so Ding is not a kind of contributor,
apparently he wants to continue learning about RAS about the kernel, and this is again the point of attracting
new people. Arthur is the lead of GCCRS, he also mentions GCCC, of course.
Tatagata, who leads Co-signal for RAS, Co-signal is used in the kernel for C to write what they call
semantic patches to transform source code, and they are working, Tatagata and Julia are working on
Co-signal for RAS, they have been working on that for three years, and they said that Tatagata
says that the RAS community is very welcoming, for our companies, and with this,
so RAS has given me this statement, they dedicate free full-time positions to the RAS for Linux
project, and Samsung says that they employ a full-time engineer, Google, Lars, gave this code,
I want to highlight, we are already working on multiple RAS drivers,
and see it from a future way, also gave me this statement, and they support and they have been
supporting as well as RAS for Linux, so what I want to highlight with all these companies and
these statements, and others that we have in the web page, what I want to highlight is that
there is quite a few people already working full-time on RAS for Linux in the kernel,
and if you are young and you say, I want to work in the kernel, or you want to maybe consider
kernel development as a field, please do, because there is this keeps growing, there will be a lot of
interesting, more Rusty developers, and I want to highlight as well as I said, and I said,
I said, Yahoo, through other entities, have supported me for several years, how to contribute,
as I said before, just go to the web page, read that and contact us, please, these are some photos
of the collaboration that we have, people in Cangrejos, and with that we are done.
So thank you.
Hi, so before finishing now, maybe we have some questions from the public that we are going to
go around, if we just raise your hand and we are going to go around you, and yeah, we'll be answering
now.
Presentation is over, but there is still time for questions, so if you like to ask some questions,
we still have 10 minutes, here just want to leave, go in.
Are there any questions?
Yeah, please, for example, I can answer one or two?
I have a question, does Rusty Linux as of the most recent current, I will ask for the results,
as of the recent current, is there require Rusty bootstrap flag?
So the question is, does the kernel currently need the Rusty bootstrap flag?
The answer is yes, because we still use stable releases, we support stable releases in the kernel,
and therefore, because we use unstable features, we need the flag to support those stable releases.
That's how any other questions? Any other questions?
You have one?
What's the situation with the out of three drivers?
I'm not sure what do you mean by what is the situation, there is the user that I mentioned in the beginning of the talk,
we have a few major users, like the Android binder, Nova, the ambient driver, they are walking
through the process of getting the dependencies into the kernel, the abstractions that they need to call
from the driver, so the driver needs to call some safe abstractions, and then they call the side of the kernel,
so they need to first have to stream those dependencies and then they can have to stream the driver,
but this is going, the process that is going, and for example, the Niel was mentioned in that
this year, the year of the GPU drivers, and what I think he means is, for example, that the dependencies
are everything they need, it will be ready, it is here, I hope that answer the question.
Do you have another question?
Yeah, you can ask him directly.
You are the next presenter, right?
Well, do you have a ready to stick your laptop?
Well, remember, we did it once, once you said, how much time frame?
Oh, yeah, just a few seconds.
Oh, no, I mean, time frame in the sense of, no, no, the change in the rest, the change in the rest,
one year or two years, is it going to all be all the rest eventually?
Okay, so the question was, do you think the kernel is going to be converted from C to R
than what time frame?
I think we, I mean, seeing the kernel, there is millions of lines, I don't think,
is going to happen anytime soon, what is going, what is actually happening is
there is rest subsystems that want to use or want to use rest, and people is targeting those,
but most of the cases we are not replacing C code, we are already in new drivers,
or we are adding what we call rest reference drivers, which are a way to duplicate a driver,
which is not possible to do, but it is a way to, you know, start in the subsystem with something
that you are aware, as I'm saying, you know what is the C side of the C equivalent of the driver,
so you have the equivalent of the driver and you can continue from there.
So I would expect, we see more of those, I expect to see the user, the media users, I list it also
to get into the kernel, but I don't expect any time soon replacing C code,
at least next year, next year, we, what I think will happen is that we will start to see
maybe new subsistence with any rest from scratch, okay, or, yeah, sorry, they say that time is up.