 Hello, everyone, and thanks for coming to my presentation. And the presentation is about Rust in kernel CI, but it's mainly about kernel CI. And Rust is a catch phrase. But I will talk a bit about Rust. So I'm Hariso Tachibana. And I am a gen2 developer. And I'm part of the kernel CI Technical Serene Committee. I'm part of the CRP. And I work for Cybertas Japan. So about this presentation, most of the things that I say that is right in my presentation are mostly my opinion. So I will talk a bit about what is kernel CI and what is Rust for Linux. But I think most of you know probably what is kernel CI, what is Rust for Linux. And then I will talk about what we are implementing in kernel CI for testing with Rust for Linux. So kernel CI is a continuous integration system that is used by the venus community. And it sends some major report to stable mailing list and to some particularly sending to Greg. But everyone can see from the mailing list, can see the report of kernel CI. And kernel CI is trying to take a distributed approach. So every part is practically can be distributed theoretically. So kernel CI is done by the Technical Serene Committee and advisory board. And we are meeting the Technical Serene Committee one at a month. And I think also the advisory board. But I'm not sure because I'm only in the Technical Serene Committee. And there are some members that are supporting work of kernel CI. So kernel CI is helping practically keeping what we at least giving a view on what we are adding to the kernel. And see that nothing's broke. So why is it scalable? Because it's divided in. We are using different part of kernel CI that can be installed and distributed. Lava Docker actually is still the main kernel CI laboratory. But currently we are trying to not only use Lava Docker, but also trying to use different system for testing. And we have also some repository where we are having the test definition. And we are using current Jenkins, but we are moving to a different system that is called a kernel CI API. But it's not completed yet. I think some part of it is working with that, but not yet everything. So we have not only kernel CI, but also some other operating system that are helping sending data to kernel CI. And all this data is send upstream or anywhere that can be viewed by a kernel CI website. So distributed. And we have many test labs. And everyone can add his own test lab. And we have current kernel 3 under that are tested by kernel CI, but actually there are more. And I think I didn't add the rest. Yeah, I didn't add the rest. So RAS4Linux, RAS4Linux is the project that is trying to add in support to offer us to the Linux kernel. And it is made by, I think, Mycology. Some other, where is Montana and reviewer. And the work is supported by this company. And yeah, it is adding the support. And if you want to use it, there is many guidelines, like explaining how to use RAS4Linux. And what the current thing for RAS4Linux is that is currently only support a specific version of RAS. Like you can try to probably build with all the one, but probably not everything is working. Because as explained after, RAS4Linux is using some unstable feature of RAS. And this can break when you try to use RAS4Linux. And then it's using bingen that is binding the C side of the kernel. And CLAB part of LLVM. So I think I read it. So yeah, I was talking about the unstable feature that is using RAS4Linux. And actually, there are many. And I don't know how I can show that page. There is a pending issue. Actually, I was thinking about making this a recent I was thinking about making this more for both presentation for everything that is. So this is the least of all the unstable feature that is using RAS4Linux for the kernel. And there are actually many. So and that's why only one version of RAS is practically working with RAS4Linux. And currently, RAS4Linux is using two main systems for checking every patch that is going to RAS4Linux. One is using CLAB and the other is using GitHub Action. But I think GitHub Action is currently only for like very recently deprecated the RAS branch in favor of RAS Next. And I don't know if GitHub Action is yet working on the RAS Next. And Kinesiai recently deprecated the RAS branch. So we got added one year ago. We got added the branch of RAS4Linux under Kinesiai for taking it under control. And from there, in that patch, actually, we got the branch repository. And then we got the fragment of the configuration that is going to be for Kinesiai. And we enable the module, some sample module for checking that RAS4Linux is building. But the problem was that recently we are actually not building it. And I look at why. And probably we didn't get the first part of the fragment, but only the sample part. So I sent a Pura question yesterday for asking to build both. And this one is the core practically of Kinesiai that is building RAS4Linux. And it's also building Keseptes, but I'm not sure what reason. And the interesting part is we build an environment that is the environment that is used for building RAS4Linux. So Kinesiai is practically each build of its own environment. And RAS environment is based on slang plus some RAS component. So I wish you after, but we are making the doctrine of RAS4Linux. And actually, anyone can use it. And we have a patch with the sender actually yesterday. And we started to build some module. But actually, I still have to think about what we have to do with such like OK to build, but what other tests can be done. And if such tests are enough good for Kinesiai. And so the first part of the building feature that we was making the doctrine of RAS4Linux is actually on everyone can download that and play with Kinesiai doctrine of RAS4Linux. So the doctrine of RAS4Linux is another fragment in Kinesiai. The first one was Yamle. And this one, I think, is Jinja because it is practically just the docker-compose part of the docker-building image. And we're trying to follow RAS4Linux. RAS4Linux is helping us with sending some patch. Like when we are stabilizing the new version of RAS4Linux, we are sending us, usually, the patch for the new RAS4HUDDing new version of RAS4Linux. So we're actually trying to collaborate also with RAS4Linux and RAS4Linux is collaborating for RAS4Linux. I sent also some little patch for RAS4Linux. So the docker-compose part is practically just getting the RAS4Linux toolchain. And with RAS4Linux, it's just installing the toolchain that we have. The RAS part is then work it by another part. And install the Jinja. And then I think it's installing also RASFNT, that is the format in Kinesiai for RAS4Linux. And then we have also Clippy, but we are not using Clippy. So it could be a new feature of what we want to test with Kinesiai. There is on the canal.org, where the computation is right, the minimal version for building with RAS4Linux in the canal. And you can also do some RAS4Linux available for knowing if it's building or not. So I was saying recently we divided the RAS branch. So a new development branch in RAS4Linux, it became RASDev, but it's not yet under Kinesiai. We have a problem of putting everything under Kinesiai, but we also need to see that we are not overflowing with the source of Kinesiai. So this one is how you can see from the web page about the build of RAS4Linux, checking that we are building RAS. So in the Kinesiai web page, if you click on the build option, you can add write RAS in the search, and you will see all the build that we are doing for RAS. And currently, I think in the production version of Kinesiai, we have probably really few build. And we are mostly building on the staging version, that is the development version of Kinesiai. So I'm trying to move in such things to the production of Kinesiai. And yeah, we need author of Kinesiai and RAS4Linux. Yeah, if you click on the result on the build status, you can see. But I think also by the mail that is sending each time, I don't know if staging is actually sending the mail. We will try to send the mail from now on. I don't know how it's feasible. And if you see on the build, there is the log. And on the log, you can see that actually building RAS, but these need to be automated. And please, not automated, I think. At least they just automated the fact that if nothing broke, it's OK. But Docker, that build, and that is the node name, that is RASC, the last version. So in the future, Kinesiai is currently building RAS, but it has not so much of testing of RAS, some part. But it's using the sample configuration that is inside the RAS4Linux, that is building some module and say that is everything OK. But I think recently, and that's why we had a sample. Because actually, we are both competing in the sample in RAS, but we are doing the same thing. And actually, I'm not even sure why we had both. And I think one of the sample parts are not building, because I tried yesterday and I couldn't. I found only the print and some part of it. It was a mix of RAS4Linux sample and RAS2 sample. So we probably have to fix such things. So another thing that we can use is using Clippy. It is very interesting that is used by RAS4Linux, but not everything that Clippy found is actually a problem for RAS3N kernel. So I try to send some pre-quest about that. Some got closed, some got merged. I think few of them got actually merged. And then recently, I don't know the pronunciation, but I will introduce Cosinell for RAS at the last RAS4Linux workshop in two months ago. And we actually have a Cosinell Docker environment on CNSI. So I actually don't even know if it's actually used by CNSI if we just have such things. So this could be an interesting part of making Cosinell check-in, also checking RAS4Linux. So I don't know if someone is interested about looking into this. And then also this one, I think this one is more old, but I read about that also two months ago, that they recently would use RAS3C, Cosinell GCC, for building RAS4Linux with GCC with this patch. And so we could also make a Docker for RAS3C or the GCC. So this could be another option. And another thing that I was talking about on RAS4Linux on one of the requests that sent to CNSI was that we are currently following the maximum version. One only version of RAS4Linux. But in the future, he said that it will be also the minimum and maximum version. So probably CNSI will follow both. But it's still about how many resources we can use for checking everything. Me or some other person will try probably to send a patch for this in the future. But I don't know how much it will be near. Probably the things that has to be done before thinking about this is probably about the unstable future that RAS4Linux is using on RAS2. So the conclusion is not actually a conclusion. It's just RAS4Linux and CNSI. And I don't know if there is any... Also this is why it probably was better to make a both and not a presentation. If there is any suggestion or any question, I don't know anything about both CNSI. Well, probably more about CNSI when RAS4Linux. If you have any question, anything, I can try to reply. Also if it's not about RAS4Linux, if it's just about CNSI for something. If there is nothing, I'm OK also. Can I say documentation? You have RAS4Linux documentation, so if you want... So anyone can add a test to kernel CI? OK, I have to repeat. OK. Yeah, CNSI is practically on GitHub, so anyone can send a request for CNSI. Probably it's also about... If I send a request to CNSI, will that request be good for CNSI? Will it be merged by CNSI? I think the best is anyway sending something. Also opening an issue and asking, is this future good for you? I'm not the only technical steering committee. We are... I don't know, I don't remember how many. We recently became less too. Minus two. So anyway, one of them we reply. But I think it's good to see that there is involvement in CNSI in any case. So if there is something that you want to change in CNSI, please send. The only things that I get a bit strange at myself is that currently we are trying to replace Jenkins with something else. So if there is a patch for Jenkins probably, I don't know how much it will be accepted, such things, because... But if it's like I want to add this tree, I want to change, or I want to do this test, or that test, that I think you can anyway send. It's more than welcome. Yeah, yeah, yeah, that is more than welcome. Adding just to the kernel. That's done through the same repository? Yeah, yeah, yeah. That is more than welcome. And currently we are doing such things with lava, so practically use some lava. But also send also if you send like... Probably also draft, request, sending like I want to add this one and that one and then someone will come out and tell you how to add like the lava part or where to add. If you're interested about the test, there is the testing framework repository I think in CNSI, and you can see all the tests that he is doing on lava. And other part is Docker. We have... One can be the test config. So you can go to the CNSI core config or test config and there is all the configuration of the testing. And you can see where he's getting such things. And probably if he's ginger too, he's probably from lava. And... Wait, if he's ginger too, he's just with... Yeah, he's probably from lava. And this is the list of all the tests that are done during... And another one is... This is the Docker part where there is also the RAS and there is the CoSineL one. Yeah, somewhere here in this... where is CoSineL and the CVA hunt. And yeah, there are a bunch of things that are used also for testing, not only for toolchain. Yeah, the last one that I was saying was the framework test definition. That is all the lava test definition of it. Yeah. In any case, showing that there is some interesting, some testing more than other testing is anyway good, I think, and showing that anyway there is interesting in building such things. I don't know. I think RAS for Linux was first introduced by a Kinesiite developer, I think, and then RAS for Linux community started to help keeping the RAS for Linux testing updates. That was the reason from one year ago. Almost after we got the first, as we started to go, RAS for Linux community. So showing that very interesting, I think it's good for showing that there is also such things to the community that could be a good tool for keeping a check on the... There is also, I think, is also for development. I think there is some branch that just started as development version. Yeah, so there is also such possibility. I think one of the things that I try to say is that with the change from Jenkins to Canon API, it would be nice, probably, to give such possibility by some credential that is giving the possibility to send some code or something to Kinesiite. It will be such a... I don't know how much it will be implemented of it. Yeah, but probably my... I am starting to devogate on the question. If there is any other question, anything else? Thanks for the presentation. I'm trying to access to the KCI-DB dashboard. Oh, okay, okay. But unfortunately, it says that the dashboard is temporarily out of service due to some shortage. So does it happen often, or...? I also say it yesterday when it was. Maybe I can try next week. Can I see the dashboard walking? I think... Yeah, you should talk to Nikolai about that. Nikolai is the guy of Kinesiite that is working about KCI-DB. I see, I see. Anyway, so I'm very interested in it. Oh, thank you. Thank you very much. So KCI-DB is giving out some credentials to people that want to contribute tests on Kinesiite. And so, as I was showing it, the presentation, one of the first presentations was actually showing that Kinesiite is like readout in Gen2. And also, as a matter, we have our own testing system framework, but we want anyway to collaborate with Kinesiite result. So usually, the way is to add a new issue to Kinesiite, requesting a new credential for your framework. And we will give you your credential for sending your test to KCI-DB. And there is the command of KCI-DB that is made by Nikolai. So that part is mostly, I think, made by Nikolai. I also... Tomorrow is now. Oh, it didn't work. Thank you. Any other question about something that currently works? Any other questions? Okay. Okay, thank you. Thank you for coming.