WEBVTT 00:00.000 --> 00:10.000 So, welcome back. We're going to continue with the next keynote in this case is Rathful Linux. 00:10.000 --> 00:18.000 And for that, we have a very, very nice person to talk about it because it's the maintainer of the Rathful Linux subsystem. 00:18.000 --> 00:20.000 So please welcome Miguel Ojeda. 00:20.000 --> 00:30.000 Hello everyone. 00:30.000 --> 00:32.000 Thank you. 00:32.000 --> 00:38.000 I'm honored to be here. Thank you to the organisers for inviting me. 00:38.000 --> 00:46.000 Normally, for the rest of the new stocks, I give, I start to update or I give some details about what we are doing. 00:46.000 --> 00:54.000 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. 00:54.000 --> 00:58.000 Do you see what I mean when we go through a talk? 00:58.000 --> 01:06.000 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. 01:06.000 --> 01:14.000 And then I will continue with walking due to the history of the project to give you a different perspective of, 01:14.000 --> 01:20.000 to understand the project where the how we got into the place we are now. 01:20.000 --> 01:24.000 And it's just a different way of looking at things. So let's start with a context. 01:24.000 --> 01:28.000 So what is Rathful Linux? This will be very brief. 01:28.000 --> 01:32.000 Rathful Linux is a project that will be in Rathful Port to the, 01:32.000 --> 01:36.000 Support for the Rath's language, sorry, to the Linux kernel. 01:36.000 --> 01:40.000 This is where the fairly, 01:40.000 --> 01:50.000 Generally because on purpose because it's not, you know, about bringing Rath's into drivers only or to modules only. 01:50.000 --> 01:54.000 It's not just about maintaining and out of three fork. 01:54.000 --> 01:58.000 It's not about loadable modules. 01:58.000 --> 02:02.000 It's really about having first class support for Rath's in the kernel. 02:02.000 --> 02:06.000 But upstream in the afternoon kernel in may line. 02:06.000 --> 02:12.000 It means the long-term goal is that if you are a kernel developer or a kernel container, 02:12.000 --> 02:18.000 you can choose where you, what do you pick, see in our days you can choose Rath's in the future. 02:18.000 --> 02:22.000 So that's the goal. 02:22.000 --> 02:24.000 Very quickly, who uses it? 02:24.000 --> 02:30.000 Well, currently in entry means in Linux is a tree. 02:30.000 --> 02:36.000 So in upstream in the kernel, we already have a few drivers or small modules. 02:36.000 --> 02:38.000 Sorry. 02:38.000 --> 02:40.000 I should not move. 02:40.000 --> 02:42.000 But we also have major users. 02:42.000 --> 02:47.000 Currently outside of the kernel that are trying to get upstream and finishing up. 02:47.000 --> 02:50.000 Streaming the dependencies and everything they need to, to finally, 02:50.000 --> 02:54.000 within the driver, because it has to be done in step by step. 02:54.000 --> 02:58.000 So you first have to upstream the dependencies and then you're upstream the driver. 02:58.000 --> 03:02.000 So for example, we have there in the list Android binder, which is successful, 03:02.000 --> 03:04.000 and eventually goes into Android phones. 03:04.000 --> 03:08.000 It means that millions and millions and millions of people will be using it in all Android phones. 03:08.000 --> 03:14.000 We also have Apple, GPU driver, the NVMe driver, and the, well, a few months ago, 03:14.000 --> 03:18.000 the Nova, GPU driver for Nvidia was announced. 03:18.000 --> 03:24.000 And many other efforts, as well, in different places that people are working on. 03:24.000 --> 03:28.000 Now, of course, the question is, why we are doing this to being in with, right? 03:28.000 --> 03:32.000 Why we want to put a second language into the kernel, because it has a major cost. 03:32.000 --> 03:34.000 And we recognize it has a major cost. 03:34.000 --> 03:38.000 Introducing a second language is something that we have since the very beginning. 03:38.000 --> 03:41.000 It has a big cost for everybody in the kernel. 03:41.000 --> 03:46.000 And in the kernel, as you probably know, has thousands of developers, hundreds of companies, 03:46.000 --> 03:48.000 who are recycled, working. 03:48.000 --> 03:52.000 So, yeah, having everybody agree on what we are going to do, how we are going to do it, 03:52.000 --> 03:56.000 the guidelines even for a new language, et cetera, is a big cost. 03:56.000 --> 04:01.000 So why we are doing it, and especially why we were picking rust, right? 04:01.000 --> 04:03.000 Why we are picking rust? 04:03.000 --> 04:08.000 So you have heard, I'm pretty sure, about memory safety, especially in the last year, 04:08.000 --> 04:11.000 we thought this talk about potential regulations, you know, 04:11.000 --> 04:12.000 things like that. 04:12.000 --> 04:15.000 I'm not going to board you with those details. 04:15.000 --> 04:20.000 But instead, for those of you that have done see, but you have not done rust, 04:20.000 --> 04:23.000 and maybe you are unconvinced, I don't know why we are doing this. 04:23.000 --> 04:28.000 I am going to just give you an example to pick your curiosity, a very simple example to pick your curiosity, 04:28.000 --> 04:31.000 and try to give you the reason why we are doing this. 04:31.000 --> 04:36.000 So, we have this function in see, right? 04:36.000 --> 04:40.000 Please take a look for a few seconds. 04:40.000 --> 04:44.000 And if you, if we assume that the requirements for the function, the requirements for our, 04:44.000 --> 04:49.000 our function are the comments or the documentation on top of the function, 04:49.000 --> 04:57.000 then who would say, I'm pleased with your hand, who would say this is a correct function? 04:57.000 --> 05:03.000 Okay, who would say is incorrect, or that is has a bag, because it doesn't comply with the 05:03.000 --> 05:05.000 specification, all right? 05:05.000 --> 05:08.000 Okay, some of you may be thinking, well, maybe it's not correct, 05:08.000 --> 05:11.000 because I should be checking for an adult thing like that. 05:11.000 --> 05:16.000 Well, since the specification doesn't say anything about an adult, let's put it aside as both 05:16.000 --> 05:18.000 correct in both cases, okay, well, which I cannot. 05:18.000 --> 05:24.000 So, well, here, of course, that you see the bag is obvious, right? 05:24.000 --> 05:28.000 So, the function doesn't comply with the specification. 05:28.000 --> 05:31.000 So, what about this one in the bottom? 05:32.000 --> 05:33.000 It's the same requirement. 05:33.000 --> 05:35.000 I only change the constant. 05:35.000 --> 05:37.000 So, what do you think about that one? 05:37.000 --> 05:40.000 So, please raise your hand if you think that one is incorrect. 05:40.000 --> 05:44.000 Again, ignoring the checking for an adult. 05:44.000 --> 05:47.000 Oh, so some, okay, so some hands, okay. 05:47.000 --> 05:50.000 So, who thinks this one is correct, finally? 05:53.000 --> 05:54.000 Right? 05:54.000 --> 05:56.000 So, some people don't think this one is correct. 05:56.000 --> 05:58.000 Okay, good interest in maybe to discuss. 05:58.000 --> 06:01.000 Let's assume this one complies with the requirements, okay. 06:01.000 --> 06:02.000 Let's assume this is correct. 06:02.000 --> 06:06.000 This is a correct function is something that a C programming may write in their code ways. 06:06.000 --> 06:08.000 So, you will move these two functions into a grid. 06:08.000 --> 06:14.000 Okay, and in the y-axis, we have incorrect at the top, correct at the bottom. 06:14.000 --> 06:16.000 All right. 06:16.000 --> 06:21.000 Now, this is how you would write the same functions in rest. 06:21.000 --> 06:25.000 All right, so one way of writing them, but the equivalent, let's say, 06:25.000 --> 06:26.000 and I'm always exemplifying. 06:26.000 --> 06:30.000 I'm going to oversimplify in this slide, but the way you would write the function 06:30.000 --> 06:32.000 would be something like this. 06:32.000 --> 06:34.000 Those functions look similar, right? 06:34.000 --> 06:35.000 It's syntax wise. 06:35.000 --> 06:38.000 I mean, it's something that takes the same effort to write, right? 06:38.000 --> 06:42.000 The syntax, the tokens are a bit different, but that's minor details. 06:42.000 --> 06:48.000 The both functions, the incorrect ones and the correct ones, 06:48.000 --> 06:52.000 the both sets of functions, compile to exactly the same thing. 06:52.000 --> 06:54.000 Okay, so where did you compile with this? 06:54.000 --> 06:57.000 You see your plan, the same instructions will come out. 06:57.000 --> 07:02.000 So, well, you could say, well, then what is the point, right? 07:02.000 --> 07:10.000 Now, the point is that the functions on the right side are what we call safe. 07:10.000 --> 07:15.000 And there is two minutes here of safe, and the point of this right hand side functions, 07:15.000 --> 07:19.000 even if they compile to exactly the same binary or the same instructions. 07:19.000 --> 07:25.000 The point is that as an implementer of the function, when I wrote the line, 07:25.000 --> 07:29.000 that expression, you know, access in A and access in B, and then the quality operator, 07:29.000 --> 07:33.000 I know I have not introduced any family heavier with a line. 07:33.000 --> 07:36.000 Okay, so as an implementer, I know there is no any family heavier that can trigger here. 07:36.000 --> 07:40.000 Any family heavier for those that may not know is the kind of thing that, you know, 07:40.000 --> 07:43.000 it's a memory safety issue, you can trigger vulnerabilities with it. 07:43.000 --> 07:47.000 Naysal demands, you know, coraggio memory, et cetera. 07:47.000 --> 07:49.000 So, very bad. 07:49.000 --> 07:51.000 So, then that's one thing. 07:51.000 --> 07:57.000 And the other thing that you get with the right hand side version is that the collar, 07:57.000 --> 08:00.000 as a collar of the function, not implementer, but the collar of the function. 08:00.000 --> 08:04.000 I know that I cannot introduce any family heavier either, when I call this function with any input. 08:04.000 --> 08:05.000 Right? 08:05.000 --> 08:12.000 And again, I am over-fimplifying, I am not going to go into the, you know, details of when that holds exactly. 08:12.000 --> 08:16.000 But I will show you the rest version of the left hand side. 08:16.000 --> 08:17.000 Okay? 08:17.000 --> 08:19.000 This is the left hand side. 08:19.000 --> 08:21.000 This is how you are writing rest. 08:21.000 --> 08:24.000 The same version as the, as I see one. 08:24.000 --> 08:29.000 Again, all these at the top and all these at the bottom compile to exactly the same thing. 08:29.000 --> 08:31.000 You see there are two colors. 08:31.000 --> 08:36.000 That's the meaning of the two of safe safety things that I mentioned. 08:36.000 --> 08:40.000 One is that I don't introduce any family heavier as an implementer and the other is, I don't introduce. 08:40.000 --> 08:44.000 And the family heavier as a collar. 08:44.000 --> 08:49.000 And when you think about it about the and the family heavier. 08:49.000 --> 08:57.000 The thing is, well, you may say, oh, you know, writing T is maybe, yeah, it's pretty obvious that they're, 08:57.000 --> 09:00.000 the incorrect one there in C is incorrect, right? 09:00.000 --> 09:06.000 But the thing is, when you scale writing code in the right hand side, when you scale T is two type programs, 09:06.000 --> 09:12.000 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. 09:12.000 --> 09:19.000 Especially as the program, as the program gets more complex, that is a review for power two properties that we get out of that. 09:19.000 --> 09:23.000 And moreover, when you consider the lifetime of the project, right? 09:23.000 --> 09:27.000 When you consider maintenance, when you consider all the changes that are going into a project over time, 09:27.000 --> 09:29.000 the risk of making a mistake. 09:29.000 --> 09:35.000 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, 09:35.000 --> 09:43.000 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. 09:43.000 --> 09:51.000 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. 09:51.000 --> 09:59.000 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, 09:59.000 --> 10:04.000 we would love to do that as well in the kernel, and I imagine in almost every single project. 10:04.000 --> 10:06.000 At least that's what I think we should do. 10:06.000 --> 10:12.000 The thing is C does, and currently have a way to write that, and neither does C++, and neither does CG. 10:12.000 --> 10:16.000 So that's why we picked Rust in particular, right? 10:16.000 --> 10:23.000 And I hope this example, this very trivial example, just pick your curiosity, if you have a seat developer, 10:23.000 --> 10:29.000 and you see this concept of, or this or tonality of safety and correctness. 10:29.000 --> 10:34.000 And again, I know it's simply fine here, but that's the point, you can have incorrect or correct code, 10:34.000 --> 10:39.000 and you can have safe code, and safe code, and all variations. 10:39.000 --> 10:47.000 So for example, you have, for example, you have, you know, you call memory copy, like this. 10:47.000 --> 10:48.000 It's the same thing, right? 10:48.000 --> 10:53.000 And if you know, you have a perfect program in C, the program is still unsafe. 10:53.000 --> 10:58.000 Because even if it is perfect, you don't get those properties. 10:58.000 --> 11:05.000 Even if it is perfect, you don't get those properties with a C code or the unsafe version of Rust. 11:05.000 --> 11:09.000 So that's the key point I wanted to mention. 11:09.000 --> 11:17.000 And of course we have, and of course we have other reasons why we picked Rust. 11:18.000 --> 11:22.000 This is, this goals slide is from the original Rust for Linux. 11:22.000 --> 11:25.000 And we mentioned other things, it's not just memory safety. 11:25.000 --> 11:31.000 We also mentioned that we believe it's going to reduce the logic, the number of logic bugs in the kernel as well. 11:31.000 --> 11:38.000 We say, we talk about documentation, we talk about maintenance, about modules being becoming easier to write. 11:38.000 --> 11:40.000 Okay, so there's other reasons not all. 11:40.000 --> 11:43.000 Of course memory safety is the big one, but there are other reasons as well. 11:43.000 --> 11:46.000 And this was a year ago in 2021. 11:46.000 --> 11:48.000 So now let's talk about the history. 11:48.000 --> 11:49.000 This is the second part. 11:49.000 --> 11:51.000 Let's talk about the history on first. 11:51.000 --> 11:53.000 I'm going to go through the pre-history. 11:53.000 --> 11:55.000 History before Rust for Linux. 11:55.000 --> 11:58.000 So you have a bit more context on what happened. 11:58.000 --> 12:03.000 First, the first thing for the first project I'm aware of. 12:03.000 --> 12:09.000 That played with the idea of ALSU Rust for the kernel is TysoKins. 12:09.000 --> 12:13.000 And sorry, if I meet pronounce Rust.ko project in GitHub. 12:13.000 --> 12:15.000 That is the earliest I could find. 12:15.000 --> 12:17.000 That was even before Rust 1.0. 12:17.000 --> 12:19.000 Many, many years ago. 12:19.000 --> 12:21.000 More than 10 years ago. 12:21.000 --> 12:23.000 Of course it was very simple. 12:23.000 --> 12:27.000 Different syntax even in Rust, but it was there. 12:27.000 --> 12:36.000 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. 12:36.000 --> 12:39.000 Fishing about Linux kernel module Rust repository. 12:39.000 --> 12:44.000 There they play with the concept of the starting to write abstractions, which is what we call to the code that you know. 12:44.000 --> 12:55.000 encapsulates the safety of the CLPIs and other things in the kernel and provides us safe API to the call for example drivers. 12:55.000 --> 12:58.000 So they started doing that. 12:58.000 --> 13:02.000 But note that both of these approaches and others are probably worth it. 13:02.000 --> 13:05.000 And I mentioned and at least one more that they know about. 13:05.000 --> 13:07.000 They are all out of three approaches. 13:07.000 --> 13:10.000 They were not trying to integrate Rust into the kernel. 13:10.000 --> 13:12.000 They were not trying to play with building code. 13:12.000 --> 13:14.000 They were not trying to upstream. 13:14.000 --> 13:20.000 They were not trying to share, for example, the standard library across all the modules. 13:20.000 --> 13:22.000 So it's module, for example, was quite big. 13:22.000 --> 13:30.000 Now, a year, the next year, Alex and Jeffrey presented in the Linux security summit their work. 13:30.000 --> 13:31.000 They said, talk about that. 13:31.000 --> 13:32.000 You can watch. 13:32.000 --> 13:36.000 And also around that year, more or less, this is not really a precise line, the red one. 13:36.000 --> 13:40.000 At some point, GitHub doesn't have created the organization back then, but we didn't really use it. 13:40.000 --> 13:43.000 That was nothing, there was no activity that year. 13:43.000 --> 13:46.000 And now we are going to shift the timeline to the right. 13:46.000 --> 13:48.000 And we are going to... 13:48.000 --> 13:49.000 Let me check, sorry, then. 13:49.000 --> 13:52.000 We are going to the next part. 13:52.000 --> 13:54.000 Now it's 2020. 13:57.000 --> 14:04.000 And in the next summer, so in the summer of 2020, at some point in Nicklesonia, from Google, we were talking in private. 14:04.000 --> 14:05.000 I was talking with him in private. 14:05.000 --> 14:08.000 We were setting some ideas a few of us. 14:08.000 --> 14:13.000 And at some point, Nicklesonia and email to the main list, and said, 14:13.000 --> 14:17.000 Well, what about the rest in the kernel and so on? 14:17.000 --> 14:19.000 What can we do our LPC talk? 14:19.000 --> 14:22.000 And T-strigger are going to LPC. 14:22.000 --> 14:25.000 So we went Alex, Jeffrey, your three-plet, 14:25.000 --> 14:34.000 Jamboblitz, your three-plet, Alex, Jeffrey, 14:34.000 --> 14:37.000 Nick and myself, sorry. 14:37.000 --> 14:43.000 And we went to give the varies in two and three kernel rest in the kernel. 14:43.000 --> 14:45.000 So that was the first LPC talk. 14:45.000 --> 14:47.000 It was a pipe dream for everybody. 14:47.000 --> 14:49.000 Nobody was thinking, oh, this could actually happen. 14:49.000 --> 14:51.000 We were still thinking. 14:51.000 --> 14:53.000 But I saw that there was enough people, you know, interested, 14:53.000 --> 14:55.000 and playing with it outside, out of three. 14:55.000 --> 15:00.000 That I took a few, I think was days one week, something like that, after the talk. 15:00.000 --> 15:04.000 And I took my prototypes that I had for interacting with a build system. 15:04.000 --> 15:06.000 And I put the first PR into the organization. 15:06.000 --> 15:07.000 We had. 15:07.000 --> 15:13.000 I ping everybody, and that was the first thing that kickleball, probably. 15:13.000 --> 15:15.000 After that, people started to join. 15:15.000 --> 15:17.000 I was hopeful that people would join the project. 15:17.000 --> 15:23.000 And in fact, they joined Adam Fiona, joined the project very, very recently. 15:23.000 --> 15:26.000 And then we will see others from the court team. 15:26.000 --> 15:30.000 So soon after few months after we did a main list, 15:30.000 --> 15:34.000 we requested a main list in kernel.org for us for Linux. 15:34.000 --> 15:38.000 Then we, this is something that people sometimes don't know. 15:38.000 --> 15:41.000 In Linux, I requested a branch in Linux, because we were confident. 15:41.000 --> 15:44.000 We were doing this was, you know, something that we don't could actually upstream. 15:44.000 --> 15:46.000 At that point. 15:46.000 --> 15:48.000 So we submitted the branch to Linux next. 15:48.000 --> 15:51.000 So the code, or at least part of the code that we had, 15:51.000 --> 15:54.000 has been in the integration branch of the kernel for that long. 15:54.000 --> 15:56.000 Right, even before that of C. 15:57.000 --> 16:00.000 Then we submitted an IFC, which is the one I link before in the other slide, 16:00.000 --> 16:02.000 where we talk about why we want to do this. 16:02.000 --> 16:04.000 Where are the reasons behind RAS, etc. 16:04.000 --> 16:07.000 Then soon after we created a solip. 16:07.000 --> 16:09.000 Sorry, we created a solip. 16:09.000 --> 16:13.000 The reason is that we used GitHub and solip because RAS was using GitHub and solip, 16:13.000 --> 16:15.000 and we needed to cross, you know, 16:15.000 --> 16:18.000 crosslink issues, crosslink stuff. 16:18.000 --> 16:19.000 So we did that. 16:19.000 --> 16:24.000 And solip was something that RAS developers were, had the experience with. 16:24.000 --> 16:26.000 And they were accustomed to that. 16:26.000 --> 16:27.000 So we used that the same thing. 16:27.000 --> 16:30.000 And solip has been a really nice solution so far. 16:30.000 --> 16:33.000 So we are also sponsored by the solip company, 16:33.000 --> 16:34.000 the sponsor of our solips. 16:34.000 --> 16:36.000 So that was great. 16:36.000 --> 16:38.000 We are very happy with it. 16:38.000 --> 16:43.000 Then after a while, we have the first maintainer summit, 16:43.000 --> 16:44.000 and the first cangrejos. 16:44.000 --> 16:46.000 Cangrejos is a RAS for Linux conference. 16:46.000 --> 16:49.000 So for example, if you are thinking of doing something like this, 16:49.000 --> 16:51.000 now the project, I'm trying to bring RAS to another project. 16:51.000 --> 16:53.000 The things I mentioned here, like, 16:53.000 --> 16:55.000 cangrejos, like the integration, 16:55.000 --> 16:57.000 perhaps the main list. 16:57.000 --> 16:59.000 What you are going to see is that I am adding things, 16:59.000 --> 17:02.000 and we are adding things to try to bring people together. 17:02.000 --> 17:04.000 So the conference idea was something, 17:04.000 --> 17:05.000 it was online. 17:05.000 --> 17:06.000 The first year was online. 17:06.000 --> 17:08.000 But it allowed us to set up everything. 17:08.000 --> 17:10.000 And then people have been coming to Cangrejos 17:10.000 --> 17:13.000 to the RAS for Linux conference every year since. 17:13.000 --> 17:16.000 Then we met in Cangrejos. 17:16.000 --> 17:18.000 It was online because it was COVID and so on. 17:18.000 --> 17:19.000 And then we had the first maintainer summit. 17:19.000 --> 17:21.000 We were invited to the maintainer summit in the kernel 17:21.000 --> 17:23.000 to discuss RAS, the possibility of RAS. 17:23.000 --> 17:27.000 And this was, again, online as well. 17:27.000 --> 17:31.000 Then months pass, and we have several versions there. 17:31.000 --> 17:35.000 As you see, the version 5 version 10. 17:35.000 --> 17:38.000 We also, another thing is, in the PC, 17:38.000 --> 17:40.000 there are micro-conferences. 17:40.000 --> 17:42.000 So we also ask, hey, or we were told. 17:42.000 --> 17:46.000 In fact, I think we were invited to have a micro-conference 17:46.000 --> 17:48.000 across RAS for Linux in general. 17:48.000 --> 17:50.000 So we did that as well. 17:50.000 --> 17:54.000 And then we submitted, it's an after, the maintainer summit 17:54.000 --> 17:57.000 because that time was the PC, the time of version 10. 17:57.000 --> 17:58.000 That was the PC as well. 17:58.000 --> 18:00.000 That year, we had a maintainer summit as well. 18:00.000 --> 18:04.000 That's the maintainer summit where Linux ask everybody in the room. 18:04.000 --> 18:05.000 What do we do about RAS? 18:05.000 --> 18:08.000 We try to experiment with RAS. 18:08.000 --> 18:12.000 So we allow the RAS experiment to go in entry to get merged. 18:12.000 --> 18:15.000 Nobody really complained at that moment. 18:15.000 --> 18:21.000 So we went ahead and Linux took the code and merged. 18:21.000 --> 18:26.000 Then we added other things like, you know, we started our webpage later, 18:26.000 --> 18:30.000 where we put everything that is related to, you know, 18:30.000 --> 18:32.000 it's like a half of links. 18:32.000 --> 18:35.000 If you want to contribute, for example, that's a web you go. 18:35.000 --> 18:38.000 And if you read our webpage, you have all the content that you need. 18:38.000 --> 18:42.000 And it allows us to update the documentation that is hard at the top date in the kernel. 18:42.000 --> 18:47.000 We also, as you see in the top later, we have RAS docs kernel.org. 18:47.000 --> 18:54.000 That is the generated documentation he rast put in the kernel.org domain. 18:54.000 --> 18:57.000 Another thing that happened. 18:57.000 --> 19:01.000 Now, I want to focus the next few slides on the other three points here. 19:01.000 --> 19:04.000 The RAS CI, the increased collaboration with upstream RAS, 19:04.000 --> 19:07.000 and the first minimum RAS support to version. 19:07.000 --> 19:15.000 So since February that year, the 2024, we had regular meetings. 19:15.000 --> 19:16.000 We increased the collaboration. 19:16.000 --> 19:19.000 We already collaborated, but it increased the collaboration with upstream RAS. 19:19.000 --> 19:21.000 Because we needed it as you probably know, and stable features. 19:21.000 --> 19:25.000 Which are features that are only nicely compiled, supposedly. 19:25.000 --> 19:28.000 So we wanted to fix that and make it stable. 19:28.000 --> 19:32.000 We were using, since almost the beginning, we are using stable releases of RAS. 19:32.000 --> 19:36.000 But we were solving the problem of the unstable features by pinning the version. 19:36.000 --> 19:37.000 We only supporting one version. 19:37.000 --> 19:39.000 Now, we jump to the next fixing everything in between. 19:39.000 --> 19:40.000 And that's it. 19:40.000 --> 19:44.000 It was a reference, it was a flagship RAS project. 19:44.000 --> 19:50.000 And it's going to become another flagship RAS project goal for the next half year. 19:50.000 --> 19:51.000 So now. 19:51.000 --> 19:55.000 But one thing, and this was the bigger thing that we got. 19:55.000 --> 19:59.000 And it was the first and the fastest that we got, is that the kernel is now, 19:59.000 --> 20:03.000 or since then, is in the RAS upstream RAS, in the compiler CI. 20:04.000 --> 20:08.000 So it means every PR that is merged into the RAS builds the kernel, 20:08.000 --> 20:12.000 a very simple configuration, but it builds the kernel, and it has to pass. 20:12.000 --> 20:18.000 So that way, we were trying to edge against changes in an unstable feature, 20:18.000 --> 20:20.000 especially in the language. 20:20.000 --> 20:22.000 So that was extremely good. 20:22.000 --> 20:25.000 And it allows us to unpin the version. 20:25.000 --> 20:27.000 So before we could only use one version. 20:27.000 --> 20:30.000 Now we could start supporting the first time, for the first time, 20:30.000 --> 20:33.000 I'm MSRV, the first minimum support is RAS version. 20:33.000 --> 20:35.000 So we did that just that. 20:35.000 --> 20:41.000 And it was something that Linux requested, and I think it's quite important. 20:41.000 --> 20:45.000 And because we unpin the version, then we could start supporting distributions. 20:45.000 --> 20:47.000 So you see it's like a train of things. 20:47.000 --> 20:49.000 We started supporting distributions. 20:49.000 --> 20:52.000 And now we have support, generally, of those distributions. 20:52.000 --> 20:54.000 Things can break at some point. 20:54.000 --> 20:56.000 Still things are not completely fixed, but these are the distributions, 20:56.000 --> 20:59.000 and others that probably works on them. 20:59.000 --> 21:05.000 So you can just install, put the commands that we recommend, and it's a work. 21:05.000 --> 21:07.000 So we are back to the timeline. 21:07.000 --> 21:15.000 And here, very quickly, I give you a few more data points or time points of what versions, 21:15.000 --> 21:21.000 where of what versions of RAS were available at which time, and the Linux versions LTS. 21:21.000 --> 21:24.000 We are in LTS, and we support RAS there. 21:24.000 --> 21:27.000 I mean, there is almost no code in, for example, in 6.1. 21:27.000 --> 21:31.000 There is almost no code, but we keep it compiling, and we keep it building. 21:31.000 --> 21:35.000 6.12 LTS is the first one, where the opinion is there. 21:35.000 --> 21:42.000 So if you see 6.12, it's the first version that we will support a range of compiling versions. 21:42.000 --> 21:52.000 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. 21:52.000 --> 21:56.000 So I replace the bottom part of the timeline, and I put where people join. 21:56.000 --> 22:01.000 These are the people of quarter, where I say that Adam Fiona others that joined the project and collaborated. 22:01.000 --> 22:04.000 They were much, there is a lot of people that collaborated. 22:04.000 --> 22:09.000 But these are the people in the court team, and when they roughly joined. 22:09.000 --> 22:11.000 And I will mention a few words about them. 22:11.000 --> 22:13.000 I think it's important to have a good team. 22:13.000 --> 22:18.000 And really, the people that joined, even since the beginning, they were very, very good. 22:18.000 --> 22:25.000 For example, Watson was the arena author of the Android binder driver, the 9 piece server, the NVMe driver. 22:25.000 --> 22:26.000 Other things. 22:26.000 --> 22:32.000 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, 22:32.000 --> 22:40.000 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. 22:40.000 --> 22:44.000 As you know, with some left, but he has been a pleasure working with him. 22:44.000 --> 22:49.000 And I wish he was still working in, in restful years. 22:50.000 --> 22:52.000 Then we have Watson. 22:52.000 --> 22:54.000 I will not read everything. 22:54.000 --> 23:00.000 But Watson currently works on the cork kernel, RCU, his or her, or the memory model. 23:00.000 --> 23:03.000 And things like that. 23:03.000 --> 23:09.000 John is, I think it's well known in the RAS community, in the RAS compiler, in particular, 23:09.000 --> 23:12.000 he maintains the crane lift back end. 23:12.000 --> 23:20.000 And we, he's not that available anymore because he has a full-time job, but he's very good. 23:20.000 --> 23:30.000 He essentially, when we have a question about RAS, we just go ask him about what we, what we need. 23:30.000 --> 23:32.000 Now we have Gary. 23:32.000 --> 23:35.000 Gary, it's a very versatile. 23:35.000 --> 23:38.000 He, I think, is his or her part of the RAS project. 23:38.000 --> 23:39.000 He's very versatile. 23:39.000 --> 23:43.000 He knows about all kinds of stuff, you know, low level embedded, 23:43.000 --> 23:45.000 SPAs, I think, so yeah. 23:45.000 --> 23:51.000 It's another person we go through to ask any kind of low level stuff. 23:51.000 --> 23:57.000 Then Beno, Beno is, again, I will not read, but I will just give you, 23:57.000 --> 24:04.000 because we're in a university right, and this, I think, is quite important for how to collaborate. 24:04.000 --> 24:11.000 Beno, if you read it, Beno, didn't really, as far as I understand, didn't know much RAS, 24:11.000 --> 24:15.000 but within a year, something like that, I don't know how he did it, but within a year, he learned RAS, 24:15.000 --> 24:18.000 and then he started to learn about the kernel, and he contributed. 24:18.000 --> 24:22.000 And he solved, actually, a major problem we had in the kernel, the opinion it, 24:22.000 --> 24:28.000 solution that he provided, to, to, to, you know, to, to, to, to ease how we, 24:28.000 --> 24:32.000 we write and to remove unsafe coding in some parts of the abstractions that we need. 24:32.000 --> 24:37.000 And then he is working on other things, but including a, a major language feature for us. 24:37.000 --> 24:41.000 The key thing I want to highlight here is that Beno is the primary example of, hey, 24:41.000 --> 24:44.000 if you are a student, you are learning, you, or not a student, but you are learning, 24:44.000 --> 24:49.000 you want to contribute, you can just contribute. He joined, and then he's now part of the core team. 24:49.000 --> 24:54.000 And I think you can do that with RAS for the new RAS for the new RAS project, he just need to start. 24:54.000 --> 25:00.000 And RAS, and RAS, work in, originally, at Western Italy, and, and then, at Samsung, 25:00.000 --> 25:08.000 he has been fighting the, hardest, I think, he has had, sorry, the, the hardest fight in the kernel, 25:08.000 --> 25:14.000 because the, the project that he took, which is the envy of the RAS and, and, and, 25:14.000 --> 25:19.000 and the, and the abstraction that he needs, require, to talk to maintainer that, 25:19.000 --> 25:24.000 where not, or are not, really, a pro-RAS. 25:24.000 --> 25:29.000 Then, Rafael is, Alice is also very well known in the, in the, in the RAS community. 25:29.000 --> 25:36.000 He's usually our experts on, on RAS stuff, we, we go, to her on, on, on language, since. 25:36.000 --> 25:41.000 He was a Google, and, and he's, continuing, the, the, the, the, the, the, the, the, the, 25:41.000 --> 25:45.000 the, the Western started, like, Andreas is continuing the envy of the river that, that, that, that, 25:45.000 --> 25:51.000 it started, so, uh, yeah, Alice is, uh, like the others, it's, yeah, they are all incredible. 25:51.000 --> 25:55.000 Travor, I picked the, commit message, um, when Travor joined, 25:55.000 --> 25:59.000 this is the commit message in the kernel. Uh, Travor's part of the RAS community, 25:59.000 --> 26:03.000 he also does the working, and he maintains the, in the kernel, 26:03.000 --> 26:10.000 maintains, uh, two fighters, uh, on his part of several teams and so on, so, yeah, 26:10.000 --> 26:15.360 I know the very talented person and finally we have Daniel O'Witch, who 26:15.360 --> 26:21.320 has done literally a few days ago, was made official. Daniel O'Witch, the 26:21.320 --> 26:28.360 maintainer of the Alok API in the kernel, the rest of the API, and he is leading the 26:28.360 --> 26:35.560 nova driver, that I mentioned before. So I want to give, let me, I want to give 26:35.560 --> 26:42.640 a very quick mention about DCC, especially because we have a phosem. So I think it's 26:42.640 --> 26:49.360 very important for DCC to get into the train of rest. I know that is the front end, 26:49.360 --> 26:54.400 that is the back end, there are several ways to use DCC, even other ways that could be in 26:54.400 --> 27:01.040 the future, like the C-back end. But what I want to emphasize is that I think DCC as a community 27:01.080 --> 27:06.560 as a project, should support these projects or these people behind these projects as 27:06.560 --> 27:11.520 much as possible. There is people in the kernel that you will see, want to compile the kernel 27:11.520 --> 27:18.040 with DCC, they don't want to use LVM plan. So we need a solution for DCC and these solutions 27:18.040 --> 27:24.560 actually are quite well advanced, but I would, I am making a call here to please come 27:24.560 --> 27:30.520 talk to me or them if you want to support them with DCC because they need to support. I am 27:30.600 --> 27:35.800 going to give you very quickly to timelines for DCC for both projects. This is from 27:35.800 --> 27:42.040 Mantany, he gave me the lead of the project, he gave me the timeline of the rest C-code 27:42.040 --> 27:47.880 and DCC, how it happened and as you can see there for quite some time, it can compile and 27:47.880 --> 27:52.120 build for Linux. So it can compile the kernel. So we have a solution already, it's experimental, 27:52.120 --> 27:59.040 but it has a solution, we have a solution that it already works to sound degree, at least. 27:59.840 --> 28:06.800 We need more support to make it this reality and make it an option to compile the kernel for real 28:06.800 --> 28:16.000 with DCC. Then we have the other approach which is DCCRS, DCCRS is a new front end for us in DCC, 28:16.560 --> 28:23.360 rather than a back end in RSI. Here you have the timeline and I will summarize saying that 28:24.080 --> 28:30.400 they hope to compile the core library of rest and modify it as far as I know in DCC 15.1. 28:32.640 --> 28:39.840 This may I think, in the release of DCC 15.1, that's also big news. From there to compiling the kernel, 28:39.840 --> 28:47.200 well the gap is still big, but there is a very real processor. Now this is the second part of the 28:47.280 --> 28:55.040 big second part of the talk. It's a bit of a surprise. I wanted to take the opportunity in this keynote 28:56.400 --> 29:06.080 to give you again a different perspective of the project. So what I did is I sent a lot of emails 29:06.080 --> 29:13.840 to kernel people to see what they think about the rest in the kernel. I emailed, as I said, 29:14.160 --> 29:21.680 a lot of 150 people, I got many replies, a 20% of the emails I sent were container reply. 29:23.520 --> 29:30.240 I want to say that the results may be biased because I try to contact people that were relevant to 29:30.240 --> 29:36.240 rest in the sense that we talked about rest, well, positively or not, in the kernel community. 29:36.240 --> 29:40.640 So I contacted people that were both positive and negative about rest, but most of them, 29:40.640 --> 29:46.240 because most of the kernel containers we talked with are positive or neutral, so there may be some 29:46.240 --> 29:58.400 bias on the response. I want to thank, of course, everybody has replied because it's a quite unique 29:58.400 --> 30:05.600 collection or compilation of replies. One more thing, I gave the opportunity to everybody that 30:05.600 --> 30:13.280 replied to a stay anonymous, and I am presenting every reply. I cannot go through all of them because 30:13.280 --> 30:20.000 there are too many, but I am presenting all of them. You have here all of them. So let's get started. 30:20.000 --> 30:25.040 Of course, all mistakes, and everything else, the bolding I did in the slides are my. 30:26.320 --> 30:33.680 So first I'm going to start with Daniel, because there is no, the codes are not in any given order. 30:33.680 --> 30:39.280 Okay, there is no order in the in the codes, but I picked this one first, because there was a big 30:40.320 --> 30:44.960 timeline related thing at the top, the first sentence. So 2021, if I will be the year of 30:44.960 --> 30:52.000 rest, computer drivers. Well, this is a bold statement, and it's a very direct, so I wanted to highlight it. 30:53.200 --> 30:58.400 Here also says, engineers from multiple companies are joining together, and given all the 30:58.400 --> 31:03.280 by in from containers companies and engineers, I would say rest the rest is definitely here to stay 31:03.280 --> 31:09.680 in this part of the kernel. So Daniel of course, very positive for all of it. He's in contact with 31:09.680 --> 31:15.760 a thesis companies and engineers, et cetera, and I think he's right at this year or at least maybe 31:15.760 --> 31:18.640 the next will be the time for for GPU drivers in rest. 31:18.800 --> 31:28.320 Then we have Paolo, Paolo is a maintainer, and I cannot present a divided story, but very quickly 31:28.320 --> 31:32.160 you will recognize names, and if you work in the kernel you will recognize, and if you don't work in 31:32.160 --> 31:37.360 kernel you will see other names that you probably recognize. So Paolo works as a kind of maintainer as well 31:37.360 --> 31:44.240 in many not just in the kernel, but also in QMO and this is I think. And he said that the challenge 31:44.320 --> 31:47.680 of writing correct, an idiomatic bindings is not trivial, which I agree. 31:49.280 --> 31:53.440 Paolo is a six-rowing, that is possible, and I'm sure that all the projects will follow. 31:53.440 --> 32:02.080 So Paolo is also positive. As you see in the top, I keep, because I send emails with some 32:02.080 --> 32:06.880 questions on topics, some people decided to write a overall quote, another reply to each question, 32:06.880 --> 32:13.920 so I highlight that in this case. And I really told me that one of the most exciting developments 32:14.080 --> 32:20.240 elements, that the potential to attract a new generation, he talks about the potential to attract 32:20.240 --> 32:23.360 a new generation of developers, and this is something important, it's something that since the beginning 32:23.360 --> 32:30.880 as I said we wanted to do, we wanted to rest to attract new people into the kernel, but he acknowledges 32:30.880 --> 32:41.360 that any big change takes time. And we have Derek, he says at the bottom the project needs to be careful 32:41.440 --> 32:45.120 to not overload the containers and distribute the increasing workload to more shoulders. 32:45.120 --> 32:50.880 This is something that we think is very important and it's very true. And we never said 32:52.160 --> 32:56.080 we are going to maintain every single part of the rest as sections in all the kernel. 32:56.800 --> 33:02.960 What we said is we need the help we need to scale things across containers. We need the 33:02.960 --> 33:08.400 maintainers help to succeed here. This is something that we said in the very first maintainers 33:08.400 --> 33:12.320 summit in person about the rest for leaders, and it's important to highlight that. 33:15.760 --> 33:21.360 Carlos Ibao says rusts, because weaknesses as a language is a relatively few people speak it. 33:22.560 --> 33:28.320 It's true, I agree, that's the main problem right now that the maintainers, I think the main 33:28.320 --> 33:31.440 problem is that the maintainers don't know rust, and they don't have the time to learn rust 33:31.440 --> 33:36.960 in some cases. If they knew rust, they could probably use it as they, some of them say in the slides. 33:38.960 --> 33:43.840 Fiona, if you want to contribute to rough renews, I say since very, very early, 33:46.000 --> 33:51.520 use a space rust is helpful, but also not too much when using both a custom log and no 33:51.600 --> 34:02.080 study. It means I think that if you do use a space rust, it's useful of course, but you need 34:02.080 --> 34:13.040 more, at least to in my opinion, here, at least to write as sections. She makes a point about the 34:13.040 --> 34:17.280 C-function, C-function is often lacking documentation, this is something that has happened many cases, 34:18.160 --> 34:25.280 that kernel developers don't want to work in rust. They need to go to to read the 34:25.280 --> 34:29.520 implementation, because there is no strong documentation or precise documentation, so we need to go 34:29.520 --> 34:36.320 into the C-side of the kernel and figure out how things are going to make safe interactions for those. 34:38.720 --> 34:44.640 Then we have Stephen, who is a criminal trainer, he says in particular the obvious, 34:45.200 --> 34:50.240 speaking about whether rust could be used for kernel development, he says the obvious one is 34:50.240 --> 34:56.320 memory safety, the memory safety gives, and that's really the downfall of C. I think that's quite 34:56.320 --> 35:02.080 a strong call, but it's pretty nice. He thinks that rust will continue growing in the kernel, 35:02.800 --> 35:11.040 but that he requires thinking differently. If we had a subset of C, that would be nice to use, 35:11.040 --> 35:18.320 and it would make perhaps rust obsolete. His company uses it, but there is a code code, 35:18.320 --> 35:24.480 it's not yet a candidate, for us code. He talks about, again, young developers, 35:25.760 --> 35:31.280 at least again, a point that a lot of people also bring up. Then we have Kent, 35:31.840 --> 35:39.200 sorry, we have Kent. Kent has given me quite a few interesting points, I will highlight too. 35:39.360 --> 35:47.680 One is this one, so he says C and even more so kernel C have an enormous learning curve, 35:48.480 --> 35:55.280 and he says rust helps that with that. So instead of thinking, oh, rust is harder than C, or kernel C, 35:55.280 --> 36:01.920 is the other way around, if I understand correctly what he is saying, it's better to deal with rust than kernel C. 36:02.000 --> 36:08.560 So I thought that that point was quite interesting. And then this other one, 36:09.360 --> 36:14.880 where I say what he can says is a wide open field, with lots of interesting technical 36:14.880 --> 36:19.040 problems still to be solved and cool work waiting to be done. This is something that I agree with. 36:19.920 --> 36:22.880 In the kernel, there is many things that are already done, that there is a lot of people that 36:22.880 --> 36:26.560 have been working there for decades, and maybe young people say, oh, you know, everything is done, 36:27.280 --> 36:31.280 I don't want to get into kernel development. We rust, we hope that is the opposite, 36:31.280 --> 36:36.320 because you can take any part of the kernel, really. And start thinking, how do I rub these APIs? 36:36.320 --> 36:42.160 How do I rub these Cs, Cs, Cs, Cs, C APIs into safe abstraction, and I provide a better API 36:42.160 --> 36:46.880 for drivers and so on. So I think this is a very, very important point. 36:48.560 --> 36:54.000 Then we have the June, who may also, a good point here in the first one, I will say, 36:54.000 --> 36:58.560 be the others. He says, the June says, I think memory is 60, a more extractor design and programming, 36:58.560 --> 37:02.720 which are encouraged and formed by the language, which will be beneficial for the kernel, 37:03.520 --> 37:11.040 while also being an obstacle to adoption that is. I think that's, yeah, that's fair, completely fair. 37:11.760 --> 37:17.840 He told me that he, he was just blabbering. I think that he knows, he's quite a smart, 37:17.840 --> 37:22.320 knows a lot, so I don't think that's blabbering, but he told me, hey, please know that. 37:22.400 --> 37:31.040 He also mentions that there is an uphill battle in the kernel, and long term gains are to be had. 37:32.480 --> 37:37.760 Luis makes the point of GCC, so the what I said before Luis makes the point of, 37:37.760 --> 37:44.240 hey, we need GCC support. For many maintainers, it's quite important, it is part. 37:45.520 --> 37:50.960 Myra says that with more than 30 years of history, the kernel has deeply rooted values on the structure, 37:50.960 --> 37:56.240 making it different, difficult to change its curves, and for us to succeed, it cannot be a second 37:56.240 --> 38:01.040 class citizen. It must be a first class citizen, the goal is standard for developing new drivers. 38:01.040 --> 38:07.440 This is exactly what the pretty was about. It was about making first class language in the kernel. 38:09.200 --> 38:15.040 Hans talks about that he wants to, he would like to use rise if he has time for it, and he 38:15.040 --> 38:22.960 made with device drivers. Warframe mentions that he has no bandwidth to learn it, 38:22.960 --> 38:28.880 and no customer currently wants to pay him to learn a rest, which is again the bandwidth problem 38:28.880 --> 38:34.880 which we have discussed already, but he thinks that rest will continue growing in the kernel, 38:34.880 --> 38:42.160 and that is not going to be a revered or removed. He also makes a good point at the top. 38:42.160 --> 38:46.320 The biggest problem I see is with reviewing a rest code. He says, I simply cannot review a 38:46.320 --> 38:51.840 revered within rest, which is an interesting point for sure. And he says, I need assistance from someone 38:51.840 --> 38:56.960 who is able to do that. I can assist with, then with my assistance specific knowledge, 38:56.960 --> 39:01.200 this is something that we have already happened in the kernel. A RAS expert and a kernel expert 39:01.200 --> 39:05.680 got together, even in the mailing list in public, and also in private, and they got ping-pong, 39:05.680 --> 39:10.960 they were ping-pong in the ideas and learning from each other, and that was a, they were several 39:11.040 --> 39:14.960 instances of that, already in the kernel, and it is very interesting. That approach, as he 39:14.960 --> 39:23.280 suggests, for sure, works, and I agree with it. S.A. says that he tried to learn RAS, but he was 39:23.280 --> 39:28.080 more complicated than he wanted, but nevertheless, he says that after an announcement that we did 39:28.080 --> 39:38.400 in LPC, he plans to start using it in Daemon to make memory safer and attract more developers, 39:38.720 --> 39:46.240 and he's optimistic about the future. Now, we have David. David, he makes, again, several 39:46.240 --> 39:56.880 good points. I would like to highlight that maybe that he definitely loves to see, see, pick up more 39:56.880 --> 40:02.720 60 memory sets of features. This is something I really didn't speak too much, but I agree with 40:02.880 --> 40:07.840 Mantenes that say, as I said in the beginning of the talk, if we had, see, with memory safety features, 40:07.840 --> 40:12.960 this would be very nice, and the other point that in the slide is everybody involved, we will 40:12.960 --> 40:16.560 still need to make compromises, this is true, we will need flexibility from Mantenes, we will need 40:17.120 --> 40:23.360 solutions to work with Mantenes of subsistence that do not have time, or they don't want to 40:23.440 --> 40:29.760 RAS, et cetera, et cetera. He makes other points here that we don't have much time, so I will skip. 40:31.120 --> 40:36.960 Now, we have an anonymous kind of Mantenes, they say any sufficiently complex RAS codebase is 40:36.960 --> 40:46.160 largely unreadable without RAS analyzer. I think especially if you are new to RAS, that is 40:46.400 --> 40:56.880 very true, they are neutral on whether you will continue growing. Sorry, they are neutral 40:56.880 --> 41:07.760 that is true, but they think it will grow. They mentioned, like others that develop new features 41:07.760 --> 41:14.240 in RAS, the kernel is requires more time fighting the compiler, but when you do, it actually takes 41:14.320 --> 41:19.040 more less debugging time, it is actually more likely that you just have it correct. 41:21.840 --> 41:27.920 They also make the point at the bottom that the project is unnecessarily controversial, and I agree, 41:27.920 --> 41:32.080 we don't want drama, we never want it any controversies or anything, we are trying to avoid 41:32.080 --> 41:37.760 them since the very beginning, until something that everybody can tell you. So, yeah, hopefully 41:38.560 --> 41:45.120 less controversies will happen. Another anonymous kernel Mantenes, they described several 41:45.680 --> 41:50.320 good points, they say the resistance from some systems over individual, it is expected, but that's okay. 41:53.120 --> 42:02.800 They also say that time will resolve all these issues, and he quotes or he says that RAS guys don't 42:02.880 --> 42:10.160 really know that they have already won, well, he or C is very kind, both Linux and RAC8 want to give 42:10.160 --> 42:19.760 RAS the chance, that is a huge win, that, yeah, I agree. Then we have Arden, he says, I am a 42:19.760 --> 42:24.240 strong supporter of RAS in the kernel, although I do worry that it will make it even more difficult 42:24.240 --> 42:29.520 to make pervasive three wide changes, this is true, it's a fair point, integrating a RAS 42:29.600 --> 42:35.120 create in that manner is going to create all kinds of challenges, I expect that's interesting because 42:35.120 --> 42:44.160 we have discussed, third party creates how to support them in the kernel. We have Paul McKenney, 42:47.600 --> 42:53.120 he says that RAS appears to be the new hotness in universities, which I hope is true. 42:53.280 --> 43:01.280 He thinks there will be memories of issues in C and C++, let's hope for that, he says that 43:01.280 --> 43:06.080 the patient and persistence has been good of the project, and will likely be required for going forward, 43:06.080 --> 43:12.560 which I agree. We have Joseph, Joseph has a very strong point right in the beginning, he says, 43:12.560 --> 43:17.760 I don't ever want to go back to seed based development again, and he mentions also that he has 43:17.840 --> 43:23.360 been doing kernel development for 20 years, he maintains a fairly important part of the kernel, 43:23.360 --> 43:30.000 so it was like a very strong statement when I saw it. He also says, RAS makes so many of the things 43:30.000 --> 43:35.440 I think about when White and C are not issue. He also at the bottom says, I wish RAS were most 43:35.440 --> 43:43.440 successful in the Linux kernel, and he will be eventually. Also Greg, with permission, I put the 43:43.760 --> 43:48.880 I copied what he wrote in one of the PRs, the one of the recent PRs, that he sent to Linux. 43:49.520 --> 43:54.480 He says, I think this is the tipping point, expect to see way more RAS drivers going forward now, that is 43:54.480 --> 44:02.240 bindings are present. Tenjada Tan, Corbett, the Linux-related new editor, and also a kernel container. 44:02.240 --> 44:05.120 He says, the RAS for Linux has already achieved an important goal, 44:06.880 --> 44:10.400 proving that RAS disindeed a viable and desirable language for kernel development, 44:11.120 --> 44:14.800 that we should never the less expect a fair amount more shouting, because this is the kernel, 44:15.600 --> 44:20.080 and that he thinks this work is important for the long term viability of Linux, which I agree. 44:20.080 --> 44:26.880 I think, at least within a decade, if Linux doesn't do RAS or something equivalent to RAS, 44:27.440 --> 44:34.960 is true that we may start to see other projects, other kernel, trying to use a rango to 44:35.760 --> 44:40.800 set it. And very quickly, what other stakeholders think is also take a look? 44:43.760 --> 44:49.120 The other editor, one of the other editor, the rock, he says, on the Prami language side of things, 44:49.760 --> 44:54.000 seen a fine type using the project on language has been interesting. I think he will be many years 44:54.000 --> 45:00.960 until RAS is fully integrated, it's good to have this. RAS, which very well known in the RAS community, 45:00.960 --> 45:05.920 of course, RAS for Linux has pushed RAS towards stabilizing feature that we will also be useful as well, 45:05.920 --> 45:09.360 and it has also been a great challenge for RAS, as the kernel has quite a special needs. 45:12.080 --> 45:18.160 Tyler, who leads a language team, call it, language team. RAS for Linux is a big deal for RAS, 45:18.720 --> 45:22.720 he also says that he would like to see memory safety and interoff feature, since he 45:23.600 --> 45:25.680 would be extremely positive direction for C. 45:28.000 --> 45:34.640 John says that RAS is the point of this is his support again, and again, it's very fair. 45:37.040 --> 45:43.920 I will skip some, sorry. Ding makes, I remember Ding and saying greatly, 45:43.920 --> 45:48.160 Kindle, my interest in explain areas of the Linux kernel, so Ding is not a kind of contributor, 45:49.040 --> 45:54.080 apparently he wants to continue learning about RAS about the kernel, and this is again the point of attracting 45:54.080 --> 46:00.400 new people. Arthur is the lead of GCCRS, he also mentions GCCC, of course. 46:02.800 --> 46:09.680 Tatagata, who leads Co-signal for RAS, Co-signal is used in the kernel for C to write what they call 46:09.680 --> 46:14.400 semantic patches to transform source code, and they are working, Tatagata and Julia are working on 46:14.400 --> 46:18.800 Co-signal for RAS, they have been working on that for three years, and they said that Tatagata 46:18.800 --> 46:23.200 says that the RAS community is very welcoming, for our companies, and with this, 46:26.960 --> 46:31.840 so RAS has given me this statement, they dedicate free full-time positions to the RAS for Linux 46:31.840 --> 46:39.840 project, and Samsung says that they employ a full-time engineer, Google, Lars, gave this code, 46:40.560 --> 46:43.920 I want to highlight, we are already working on multiple RAS drivers, 46:48.160 --> 46:53.920 and see it from a future way, also gave me this statement, and they support and they have been 46:53.920 --> 47:01.360 supporting as well as RAS for Linux, so what I want to highlight with all these companies and 47:01.360 --> 47:06.000 these statements, and others that we have in the web page, what I want to highlight is that 47:06.080 --> 47:10.560 there is quite a few people already working full-time on RAS for Linux in the kernel, 47:10.560 --> 47:15.760 and if you are young and you say, I want to work in the kernel, or you want to maybe consider 47:15.760 --> 47:20.800 kernel development as a field, please do, because there is this keeps growing, there will be a lot of 47:20.800 --> 47:25.440 interesting, more Rusty developers, and I want to highlight as well as I said, and I said, 47:25.440 --> 47:31.360 I said, Yahoo, through other entities, have supported me for several years, how to contribute, 47:31.440 --> 47:38.240 as I said before, just go to the web page, read that and contact us, please, these are some photos 47:38.240 --> 47:45.680 of the collaboration that we have, people in Cangrejos, and with that we are done. 47:46.480 --> 47:49.520 So thank you. 48:01.600 --> 48:14.480 Hi, so before finishing now, maybe we have some questions from the public that we are going to 48:14.480 --> 48:21.920 go around, if we just raise your hand and we are going to go around you, and yeah, we'll be answering 48:22.000 --> 48:24.000 now. 48:30.480 --> 48:35.280 Presentation is over, but there is still time for questions, so if you like to ask some questions, 48:35.280 --> 48:38.240 we still have 10 minutes, here just want to leave, go in. 48:42.880 --> 48:44.000 Are there any questions? 48:45.200 --> 48:46.880 Yeah, please, for example, I can answer one or two? 48:46.880 --> 48:54.960 I have a question, does Rusty Linux as of the most recent current, I will ask for the results, 48:54.960 --> 48:58.240 as of the recent current, is there require Rusty bootstrap flag? 49:01.600 --> 49:08.960 So the question is, does the kernel currently need the Rusty bootstrap flag? 49:09.840 --> 49:14.880 The answer is yes, because we still use stable releases, we support stable releases in the kernel, 49:14.960 --> 49:18.960 and therefore, because we use unstable features, we need the flag to support those stable releases. 49:21.360 --> 49:24.960 That's how any other questions? Any other questions? 49:26.720 --> 49:27.360 You have one? 49:31.280 --> 49:34.800 What's the situation with the out of three drivers? 49:34.880 --> 49:55.520 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, 49:55.520 --> 50:01.040 we have a few major users, like the Android binder, Nova, the ambient driver, they are walking 50:01.040 --> 50:06.960 through the process of getting the dependencies into the kernel, the abstractions that they need to call 50:06.960 --> 50:13.520 from the driver, so the driver needs to call some safe abstractions, and then they call the side of the kernel, 50:13.520 --> 50:17.520 so they need to first have to stream those dependencies and then they can have to stream the driver, 50:17.520 --> 50:21.520 but this is going, the process that is going, and for example, the Niel was mentioned in that 50:21.520 --> 50:28.560 this year, the year of the GPU drivers, and what I think he means is, for example, that the dependencies 50:28.640 --> 50:33.840 are everything they need, it will be ready, it is here, I hope that answer the question. 50:33.840 --> 50:35.040 Do you have another question? 50:38.240 --> 50:40.240 Yeah, you can ask him directly. 50:53.600 --> 50:54.800 You are the next presenter, right? 50:55.760 --> 50:58.480 Well, do you have a ready to stick your laptop? 50:58.480 --> 51:03.760 Well, remember, we did it once, once you said, how much time frame? 51:03.760 --> 51:05.760 Oh, yeah, just a few seconds. 51:05.760 --> 51:12.080 Oh, no, I mean, time frame in the sense of, no, no, the change in the rest, the change in the rest, 51:12.080 --> 51:15.440 one year or two years, is it going to all be all the rest eventually? 51:15.440 --> 51:24.000 Okay, so the question was, do you think the kernel is going to be converted from C to R 51:24.080 --> 51:25.280 than what time frame? 51:27.920 --> 51:31.280 I think we, I mean, seeing the kernel, there is millions of lines, I don't think, 51:32.000 --> 51:35.040 is going to happen anytime soon, what is going, what is actually happening is 51:35.760 --> 51:41.280 there is rest subsystems that want to use or want to use rest, and people is targeting those, 51:42.080 --> 51:46.160 but most of the cases we are not replacing C code, we are already in new drivers, 51:47.040 --> 51:53.440 or we are adding what we call rest reference drivers, which are a way to duplicate a driver, 51:53.520 --> 52:01.840 which is not possible to do, but it is a way to, you know, start in the subsystem with something 52:01.840 --> 52:07.920 that you are aware, as I'm saying, you know what is the C side of the C equivalent of the driver, 52:08.640 --> 52:13.120 so you have the equivalent of the driver and you can continue from there. 52:13.120 --> 52:18.080 So I would expect, we see more of those, I expect to see the user, the media users, I list it also 52:18.080 --> 52:22.880 to get into the kernel, but I don't expect any time soon replacing C code, 52:22.880 --> 52:28.000 at least next year, next year, we, what I think will happen is that we will start to see 52:28.640 --> 52:36.160 maybe new subsistence with any rest from scratch, okay, or, yeah, sorry, they say that time is up.