Flock 2026 State of the Arch: Fedora on RISC V

So hey um I'll try again. My name is Kashib and I work for Red Hat for about 15 16 years 17 years already. And um I work in the community Linux engineering team on u all things Risk 5 enablement. Before that I was doing virtualization and OpenStack. So today what is this about? um just give an overview of what we're doing in the risk 5 ecosystem for the last year and al also a general overall view. So today my co-speaker David is uh not here unfortunately. He is uh he he decided to do Feder 45 rebuild instead of doing this talk with me. [laughter] I think he he's following along maybe somewhere on his stream. So you'll see the spirit of him in the room. [snorts] Um so yeah the um so yeah David couldn't make it but it's it's a talk of the community uh effort. So yeah what what are we going to talk here? So just give a rough overview of the S5 ecosystem for those who are not familiar with it and where are we with the hardware status some benchmarks we'll go over and um kernel stuff. So how do we deal with kernels and um the last one is um what is the path towards risfi becoming a primary architecture in fedora but before that it has to it has another prerequisite which is it should get into the primary cooji so what does the path look like it's being discussed and uh we want to work with the community obviously we are working on it u so yeah that's the rough outline Risk 5 ecosystem. So [clears throat] at the core of it is the open what is risk 5 right at the core of it for those who are not familiar for the core of it there is a open instruction sets uh architecture. So it's an open standard uh but the implementation of chips can be proprietary as well or open. So it is um that's a distinction and open and the the risk 5 open ISA is governed by risk 5 international or RVI and [snorts] they um there's a neutral body they're located in Switzerland and um there's a whole bunch of members that are part of this um RIFF international group many companies and and they they keep the um yeah the governing element of it they produce the whole sort of specifications all the ISA is developed openly on GitHub. So that's the risk five international um job there or it's nonprofit or so. So and and then you have um risk 5 IP vendors. The these IP vendors produce the they design the risk 5 cores which which uh are then implemented by silicon vendors like tenstor and um sci-fi. Sci-fi doesn't do um chips themselves but they produce um um the IP cores. However, Tenstor also does both IP and silicon. Then there are other vendors like Spacemate and Star Five. These are several Chinese and a few American vendors, but a couple of them were acquired recently by Colcom. It's it's a evolving ecosystem. ARM has been around for 40 years. Risk 5 exists for about 15 something years. So that's the um other two angles. the IP vendors who produce the um cores and the chip manufacturers go and produce the system on chips the boards actual boards that we end up using and then there is the rise uh project which stands for risk 5 software ecosystem and that is like the linaro of u of risk 5 so who knows what is linenaro here okay for those who are not familiar lenaro is uh um in the arm world they they're sort of the in between party that lets contributors and maintain maintainers work on upstream projects. For example, QMU project is maintained by um one of the maintain maintainers. The folks work per ARM but they work via Linaro. So and Arise the whole goal of the Arise project Arise initiative is to um it's commercial readiness of open source software. So later at the end um I'll talk a bit more about um their funding. So there's some funding available. I'll show you at the end uh who and how. So they let uh projects be ported to risk 5 your optimizations. So that's the whole um main main focus of rise is commercial readiness of open source software. [snorts] And then there is Fedora. Fedora does the integration as we all know of upstream software and um produce a solid stable operating system for developers and many others. >> [clears throat] >> So um couple of things. So there's a lot of jargon for ecosystem. I just want to keep it the most essential bits here. The first one is are we are we >> I'm used to sometimes the the microphone the label one. No it's okay. It's okay. It's just a hassle to keep it going. Um so yeah, RVA23 is the most uh recently um frozen ISA specification and that's a couple of years ago. So that's um it's it's it's an ISA profile. A profile is essentially uh a set of base is features and some mandatory extensions like support for hypervisors and support for math intensive workloads which uh which is called a vector extension. So that's the core of um RVA23. That's the most recent um ISA specification and that's just defines the base hardware baseline. So sort of not to fragment the ecosystems because it's such a flexible ISA that um so many possibilities are there but you can get lost in the wild west with with it. So the profiles um sort of try to give like a bundle set of features that um people who are implementing chips can target that. And then the the the other uh spec that is more important is the um server platform spec. It's a nonisa specification and that is that was recently ratified meaning frozen is again a set of requirements that that give you base common sense server features um for lack of better phrase like PCIe if you're implementing you um serial console for example you need to have serial console um to for baseboard management or um UEFI and ACPI that's the one of the main things And again the RVA 23S64 that's the set of base extensions. So uh it's it's it provides operating system vendors to target a single image uh that single binary that can work across um compliant hardware hardware that implements this um spec. Yeah, this is a community work. So I just want to um give a shout out to all the folks that are doing the good work there. David is right now rebuilding 45 on Feder's fi metrics. If you go there, you'll see him debugging or saying whatever that is on fire. And [snorts] um so yeah, I'm I'm here representing many of the u the much of the good work that's done by many folks. A bit of a timeline. So it's 2016 is when uh risk 5 bootstrap started in Fedora. I started last year actually around March something and Richard Jones from the federal community I think many of you may may know or some of you may know here um he's a prolific contributor Richard Jones started back then and David um started right after so he's been around also as long as Rich and then there were at the beginning there were like emulated builders and slowly we got real hardware that is not that fast or takes seven eight days I think to build some packages maybe longer. Um then of course the middle ears was all porting the 20,000 plus 24,000 packages of Fedora I guess to uh risk 5. There's a lot of grind involved there. So it's still going the last bit of uh there's a last mile work involved. We'll talk a bit about that at the end. Um and then what uh okay yeah we also got as as as time passed by we got more and more um vendor starting starting to implement chips that you can actually use in build system. So 25 was particularly interesting uh not because I joined effort um until then the risk 5 secondary koji server was running David was maintaining it by himself and we moved to official federal infrastructure and that's risk five-co.org And that's um we also had federal 42 release at the same time of uh the primary architectures. So that's alo first time thing. Um there's always at this point in time in risk 5 u life this delay is expected between the primary arch and the uh secondary architecture because yeah there's builder shortage sometimes and and it's not yet in the primary koji. So there's always you need to debug something. So it's completely expected and normal behavior but it turned out for federal 42 it was uh all uh on time [snorts] and there was also rail developer preview but this is not the forum to talk about it um rail 10 that was released the first one there's a links out there that people were interested in it there's another one that was released uh followup to this preview a couple of weeks ago or last week even and u 43 was um that in 25 we had um some problems during federal 42 rebuild but much of it was resolved by just working with the upstream maintainers bin noodles um there were also issue with debug edit so all this were sorted out uh but this takes time and effort persistence [snorts] um we recently released 26 Feder 44 uh images were out about a month of delay um we had it was smoother than Feder 43 but there were still some hiccups GCC issue there was CMC transition David probably will recall more as he's doing a lot of this stuff and one of the other interesting things is um copper C roots and I'll talk about it a bit more it's emulator builders emulated builders um okay so that's that's what I was referring to in the previous slide so the rebuild is done the images are there for picked it up a couple of days ago Um yeah, one of the other things that is uh particularly new in the Federal 44 timeline is the so-called omni kernels. Um I have a whole section about it, but very briefly, it's a single kernel that can boot across several different boards. So that's the basic idea. [snorts] Um I will show you how it was before that um idea came into existence. Um yeah that the the KJI server I was mentioning a bit ago that's now in federal infrastructure and there's of course a lot of work involving changes from there's a secondary disc kit that is maintained with some specific patches and that need to be ported over to the main Federa disc. So there's a lot of that work involved and most of it is done but the last mile difficult bits are there. Maren uh from the Federai community is doing good work there. Um I have a slide a bit more about that for those who are interested to chip in with debugging and so on. One of the other things is the um built um building images. So before um I don't know before 20 early 25 they were using a local images. So now it's all built towards um classic federal infrastructure. Kiwi and um Koji the whole I have not done it myself but um there's David did it and Andrea um from the community did some of this work. So if you're more interested in details, just hop on the channel metrics channel to figure out that the last point the federal copper builders that's the QMU builders to run uh to build kernels and you can build other things too. So you might think hm emulated builders would be deadly slow. So, but it turns out there's a um high beefy enough machine that is that can run um that can build the kernels. So, these are five six hours or something like that. So, it's quite fast compared to what hardware is doing. But I'll get to build times uh um when in the benchmark section. Okay, a bit about uh where are we with hardware. So before I go on um earlier at Fostam last year there was a really interesting talk by Emil um kernel engineer at Canonicle he gave an overview of um these um chips and boards from 2018 to 19 sorry not 19 24 you can tell [snorts] how awake I am 2018 to 24 so I don't want to repeat off that you can see um that talk um he gives a good overview um this is this is covering the boards afterwards So this is uh one of the main um machines that is doing most of the builds in R5 Cooji. It's the SCI5 vendor and it looks like a scrappy machine on my desk but the dressed up version is quite nice as well. It's server um chases and so on. But I was bit lazy because I was fiddling with some things and that power um is a bit overkill for this. But I I bought it because I have another risk five accelerator card that I want to use. So it's it's not just for this. A lower power um can also be fine. And most of Ferros it's reliable. most of the federal builds especially the heavy duty packages like GCC LVM sometimes kernel 2 um because Feder only accepts um native builds right so um that's one of the golden rules so of course kernel is also built on um this hardware physical hardware so it's based on um a semiconductor maker called ewin and um much of these um peripherals of this board are upstream some are not yet. Um if you're interested in what those are, you can check out the link uh links at the bottom throughout the talk. I have um links for those who are interested in more the gory stuff. [snorts] I think serial console will work and maybe the the clock um was also merged. So I didn't check the latest. I'm not tracking so much um going on. So always that's the other oops went too fast. That's the other uh vendor um Tenstar and they're very um interesting company. Um their CEO uh is Jim Keller. He was u CPU legend. He is still legend in the AMD infrastructure AMD uh CPUs. He was designing some of those. So they really know what they're doing. What is also interesting with Tenstor is they they they're also good at um open source um software. They working with the Linux community upstreaming. So, this board is a bit of a novelty board, but it is still um interesting in the sense it's an accelerator card um AI accelerator card that um you can plug into a PCIe 5.0, the faster one to get the max bandwidth from it. Um I have one of those. I haven't tried it yet because I just shipped it couple of weeks ago and my server is too old to plug this in. It's um 3.0 or something. But you can plug this in in something called a eGPU dock. It's a kind of docking station where you hook this up and you it has a thunderbolt port. So you can drive Linux and most of these um board is um upstream. The patches are there. You can even boot the mainline kernel with limited access with um like serial console with open SBI stuff like that. But still it's quite uh interesting in the sense that they're working to upstream stuff. That's the that's the important thing right um when the the software and the hardware owners working closely together. So that's they also have um I saw the at risk 5 North America summit last year racked up version of these so you can get beefier with liquid cooling and so on. I had some images that I uh wrote in my trip report. I can link to that. It is linked actually at the end of the references. And this is um interesting because this is the most recent um board based on the latest um ISA spec. It looks kind of not very robust, kind of looks small, but it packs quite a punch. Um why? We'll see numbers. So this uh this is compliant with the uh RVA23 specification and it can um it supports hypervisors and math intensive workloads for AI and ML stuff and it does provide a pretty solid performance leap in meaningful leap compared to our previous workhorse machine from sci-fi P50. So what that is we'll see again what about upstreaming they're doing really good work um the spacemate in terms of working with upstream kernel their device tree blob is already in the upstream kernel um there's um they have a whole wiki page actually if you click on the working progress link you'll see what peripherals are upstream what what are in progress and so on so and this is actually available to buy right it's not just somebody who can who has a special access. The whole point is the ecosystem will only work if you have if developers can buy this. So it's available to buy and we already have it in Federa Koji infrastructure and one more is on its way and um it's a bit of a hybrid machine in the sense that it has eight general purpose cores and eight AI cores. So um the general purpose cores are what we care about in in terms of building Fedora. So we'll we'll see the numbers for that. [snorts] This is another um board uh from a vendor called M5. Um this is based also on the chip that I mentioned in the previous slide from Spacemid the K3. So it's same system on chip but they have their own some additional peripherals. I don't have access to it yet, but I was sold just yesterday. This is um available to be bought and some eight or 10 of them um are being procured. So this is same performance should be as as as the previous one uh spaceman K3 also RV23 complaint because the same system on chip. We'll see what that is in a minute. This one I talked about 10 to a bit ago. This is not the hardware itself. This is um their tensor's most uh recent um ISA um RV sorry RVA23 based um board Atlantis is the board but this is the FPGA the FPGA running the ISA core from this Atlantis board. So that FPGAs as some of you or all of you may know are programmable chips that will let you test your silicon before it goes to manufacturing. so you can catch the bugs beforehand. Um otherwise gets really extremely expensive. And these are pretty uh powerful um FPGAAS. It costs almost as much as a sports car apparently. I don't know which one though. But um and this is supposed to be at the end of this um this year or early 2027. That's what at least the 10 strong guys I talked to last week actually. I was in um Bolognia, Italy where we had risk five summit Europe. So there they said that. So we will see if that shows up. And there the boat that is the emulated board is merged in QMU. If you're using QMU it's you can actually try it out and and see the peripherals and so on if you're interested in that kind of stuff. Of course what is most u important as always the Linux upstreaming that is always in progress already in progress. Tens folks are good at working with upstream but um the boards are yet to come. They had a small glitch or something in silicon um production process, but it's on its way is what they told me. [snorts] These are a few more boards that I saw last week at um um Rify Summit. Again, some of these are older boards. They're not very interesting if you're interest the middle one is not interesting now because we have the most uh recent um hardware that can do builds much faster. But these are um people are still using some of these the the middle one with racked chips. You see that one um there is a cloud vendor called scaleway small one in Paris and so they pro they provide risers for developers doing wiring up their uh software porting their software to risk 5. So um there's a couple of other boats I I I don't have access to all of those boats myself. Um but yeah, some some do. If you're interested in what board to pick, we'll see uh in a minute. Okay, we've seen some pictures of these boards, but how do they actually perform? Let's look at some of the benchmarks. P550 is the current workforce, just the terminology, and K3 is the most latest hardware. So this is just a basic uh XZ compression of um Federra ISO and um see how it compresses. Uh the [clears throat] as you see there the single core performance is is quite quite a good leap. Now as I mentioned earlier the K3 hardware has um what what what it calls eight general purpose cores and eight AI cores. You might think hey if I run on AI coursees it might perform faster but it's actually not. So, so I I ran a test where um running the same um benchmark of compressing this ISO file vera 44 43 I guess when I did that on the general purpose course it it outperforms it by like three or four minutes that's pro that I I talked to the hardware render and they said it's because the AI course the L2 cache is sort of smaller but on the general purpose course it's slightly bigger so there's details that not All workloads work on AI course equally. So this is expected behavior. So the guy confirms that's um the basic exit. What else? But we're interested in builds, right? Federal is interested in builds. So what uh these are the more most um heavy duty packages or at least the top three top four probably kernel gypsy. GCC E gypsy. As you see, if you pay attention to the middle, GCC takes 5 days and 13 hours today on the most uh or our workhorse machine until until now. [snorts] But the most recent hardware slashes that time by two two-ish days. So that's that's what I was referring to as a meaningful performance leap. It's not there at x86 levels. Obviously, it's a slow grind. A bit of it has to it will take some time. You need another leap in performance. So that's um that was quite um interesting to see how it how it performs. So I was doing benchmarks throughout the last weeks for for this talk. There's a Federra for ticket with more details if you're interested in it. Sometimes I had to do a small intervention like disabling debug for for one or two packages but most of it is just classic federal bill. It's nothing no uh nothing else added to it, nothing else deleted. Um yeah, in all these benchmarks we um use just the classic eight general purpose cores we care about. Um the AI cores were idle and when we do use AI coursees I will flag it but so um for for builds they will all be done on the um eight general purpose cores. So you can't think of it as hey there's 16 cores I can combine them all. It kind of gets messy. So the recommendation is just to run on the eight um main coursees. But for other if you have math intensive workloads they can be done on the AI course. So I haven't done those benchmarks yet just lack of time but that's um some some other people have done on the internet starting to do some of the more intense LLM inferencing stuff like that. So you can check that out. Okay this is the same slide as before but I just added in the um ARM in in it 64 number. to sort of zoomed out version how how we perform with with ARM right the the blue light light blue one um as you see it's about uh currently it's still not there 3 hours uh on the latest hardware three-ish and on AR 64 these are whatever we're using in the primary cooji system so that's like about an hour it just means it needs another leap in in hardware so just have to give some more time as as I was mentioning at the beginning ARM had 40 years to be where it is today and the hardware vendors have to keep producing the silicon that's it also hinges on them. So that's that's the sort of comparative numbers. GCC again 14 days versus sorry 14 hours versus two days two 15 that's still quite quite off but needs improvement. So overall the the system level software is about three threeish x slower than um ARM. what we have right now in Federra build system. So that's just a perspective to see where we are. We we know that that it's relatively slow but it's evolution not revolution. Okay, some more builds. Um, bit user spacey. Well, LVM is not quite user space, but um, gives a perspective there. OpenSSL and this was interesting. So, as you see there, it has almost 10x speed compared to the P550, our current workhorse until recently. And that's apparently I learned it about it last week. I didn't know why. Um, OpenSL has a lot of uh, handwritten assembly code that optimizes um, these um, vector stuff that's like a SIMD in x86 equivalent. I'm not um, an expert in those topics, but there's um, writeups on on this elsewhere, so I can link to it if you're interested. I can point to that. So that's um, again, so sometimes you do see this sort of outsized again for some user space packages. um QMU that's um an important package because Federra heavily uses in Federra QA QM used u extensively um developers use them so that's also reduced by almost 6x so that's quite quite nice LLVM um that's also 20-ish hours to 9 that's quite quite a good uh improvement because LLVM is one of the packages we need there's some last mile work left so we've been chipping away at it for about six, seven months. Um, so essentially some test suit failures. You just have to work with upstream, get the patches merged, debug the failures, rebuild the um software with dedicated sort of targeted rebuild. Not you don't do the entire rebuild so you don't waste all the 20 hours of time and and the compute, but just targeted rebuilds. So that's that's the um user spaceish software. Oh yeah and um these are again these are these are not super scientific benchmark but they're close enough give a good enough perspective um things like what storage is being used or clock frequency they they affect the benchmark so just don't take this as like super serious super scientific benchmark but this is just good enough for developers to understand where we are okay this is again same theme as before zoomed out version of um compared to ARM where we are on the same u three packages. So it's about OpenSSL again 8 minutes. It's not not a lot. Eight half half the time and cumu is 26 again half the time compared to the latest hardware and risk five. So it's um as we saw system software was 3x 3.5x slower and user space is about two twoish slower. So if if this trend continues in a couple of years it should it should match that. So we hope the hardware vendors will keep producing silicon some more benchmarks. So I'm not going to talk about all of this here. Um we had um just this I want to give a basic perspective but if you want to dig deep into the details for the Federa build benchmarks I'm maintaining a a ticket on the Feder for so you can go check out all the details with uh each benchmark if there is an intervention what what is that and so on. The other thing for those interested in AI stuff and ML and the math intensive workloads the vector benchmarks are interesting like system calls how they're performing. So for this Olaf Bernstein from the riskfi community is doing really good work on maintaining really detailed benchmarks um with these are really super scientific when you click on the link you will see how this is like a standard it has become in understanding how the vector stuff performs how the um how you can rely on um AI how AI workloads actually do so for these kind of things the low-level details are are in these um benchmarks and there's some older board benchmarks from our own folks from federal community rich and Andrea. So there these are also available if you're interested. Now what what what do you want to pick? What what do you pick if you're getting started? The answer is it depends what you're trying to do. If you just want to get an idea of how these things work and you don't have a lot of spare money to burn, you go with the basic uh version 52. This is uh from a company called Star 5. What is interesting about this boat is most of it is upstream. I think you can boot unmodified upstream kernel on this. So you get a good good sense of sense of that. Um and it's 200 or maybe less euros if I'm remembering correctly. I don't have this machine myself. Um, so that's vision five and and if you're interested to understand if your eventual goal is to work on low-level AI workloads, optimizing those kind of things, then the banana pie uh the BPI F3 that is interesting because it has the uh vector extension support. So vector extension is for math intensive workloads. Um so those who are doing compiler stuff were using this board in the beginning. So, this is the go-to until until recently because now we have better hardware available again. And this i5 U P50 that's been the workhorse for us in the Federai community so far. So, for all the heavy duty packages, we use this uh and we're moving now slowly towards the the last one mentioned over there, the K3. That's the hardware. If you're a developer interested in cutting edge hardware, want to do a lot of builds, a lot of compilations, just um try out some of the vector extension for AI style workloads, that's the boat you want to have. Um that's it costs about €700 and something the board the K3 and plus peripherals, NVMe, uh something like that. Um, so that's the sort of a rough um idea of what what you want to pick and tense Atlantis is also we're looking forward to this one this uh once it arrives when it arrives uh end of this year or early next year. So that's a rough um overview of what what to pick but there's more kinds of boards um but I'm not interested in many of those. I don't have access to them but there are like smaller boards embedded boards. Risfi is in many places already. probably it's already in the phone that you're using today but probably as a small microcontroller as I said at the beginning the ISA itself is open standard but the implementation of the ISA can be proprietary so many vendors like Qualcomm Nvidia is switching as well to um Risfi in some of its Falcon or whatever it's called um so yeah Google also t I forget their the the brand name so it's already used in many ways but you just don't realize it. [clears throat] Okay, this is the kernel part. Um I don't know if Justin is here but it's okay. He knows all of this. What are omni kernels? So this slide looks scary. It's a lot. So before uh until until recently uh our kernel guy Jason Mlion um in the federalis community is taking a lot of wend trees. uh there's some specific patches that require for some boards and is rebasing them on the mainline kernel and applying the RPM specific details to it and then um producing images via risk faces um but the churn in the vendor trees is not that much but still it's it's still a lot of work because you have to rebase them and this is not sustainable to keep doing it. So the solution there is the omni kernel or what we used to call unified kernel but that kind of confuses with unified kernel images. Some of you may know that. So we wanted to avoid this confusion and um instead chose the omni word omni kernel. So it's as as as the slide says it's one kernel that can boot across multiple boards about 15 18 boards. I have a list of them. So it kind of drastically reduces um the duplication and sort of consolidates a lot of this effort. So you forward port the vendor patches, make sure they work on the mainline kernel and integrate into a single Federra tree. That's the core idea. And um Jason uh not Jason, Justin was talking in the previous talk about um how Federa carries no upstream patches as close as possible to mainline kernel. That's the end goal. Obviously this omni kernel is like an intermediate step towards that. So until we get there we have to carry some 20 200 patches. I asked actually a number last night because Justin asked uh I didn't know top of my head. So these are necessary but it will eventually go away once um once you once once we these patches are merged upstream. Some of them are already in maintainer trees or in Linux next or or in mainline but not yet released. 7.1 was released. So that's the status of 7.1. And you can get these kernels um you can boot them also with QMU if if you have or if you have a board you can try them directly on one of your boards. Um the if you want to dig into the details of the patches where uh what what what are we carrying? What kind of patches? If you're a kernel developer in the room, so you can look at the kernel repo arc repo of JSONs. So that's the omni kernel idea. So with this the diagram we showed before becomes like this. So for now ignore the bottom bottom part of the slide. The top part is just um so it condenses all these trees into one or two three and it integrates them into risk five copper um one single tree and push it to risk five koji and produce the image. So it's uh much much less work um much more um consolidated easier to manage. So thanks to Jason. So below at the bottom of this um these are uh deep computing has this is another vendor. They have some laptops. Um they're not super performant but again it's a process. This framework laptops um they need a couple more trees. That's because video doesn't quite work well with that. So these these these trees are just for that thing but nothing else um crazy in there. So those are the kind of boards that um Omni kernel supports. It's about 15 18 I don't know 20 but they're all some of them are sharing the same system on ship. If you see EIC7700 so um Jason is maintaining several of them a lot of them actually several people are testing together and he's maintaining this list and trying to consolidate a lot of testing so if you have any of these boards if you want to test this omni kernel so come talk to us on um the federalometric channel okay this is the last part so what is the goal for five here right you want the First step towards primary architecture which will be a couple of years later or whenever it is going to happen is to have risk 5 in the primary koji. So this is u a brief idea. So what are the main requirements? Main thing is you need to have rackable hardware. The current hardware the latest hardware you can put them in racks but some of them don't quite have the features that um feder data center maintainers Kevin Fenzy and others expect. So they're coming close. Uh the hardware vendors are working on it. So once this hardware satisfies the requirements then they can be um racked. So the rackable sort of hardware is is one of the most important features and we're tracking the requirements. Budget allocation is being worked out. So that's one of the main main main things. And then of course um packagers package maintainers should be able to debug their packages. Not everybody will get access right away but some of them uh who may need it urgently to debug some things will uh get so we need to provide access to maintainers. So there is um also a ticket tracking that and of course not least of all these are going to be cooji builders. So we want an unmodified federal kernel to run on these builders. So that's also important. We have we're carrying about 200 patches. So eventually less of them and unmodified hopefully very soon. Very soon here is it will take time. It's you have to keep it in perspective. So yeah that's the base baseline requirements. Yeah this is the other one I said the last mile uh work in the risk fight tracker. So we have a risk fight tracker maintained by our colleague Andrea and um several others are contributing to it. Most of um the packages the porting is done. There's a small selection I think 100 or something maybe less uh that needs some work but some of these are heavy duty packages the kernel shim and um LLVM open JDK stuff like that. Um it's what what is there to do? It's the classic um upstream development work we do. see if there has failures, try to work with upstream, figure out the root cause, you know, submit the patches and so on. So, if you want to contribute any of those, um, there is the risky tracker. Maren, as I mentioned at the beginning, has been doing quite good work. He's picking up quite a lot of this and I'm sure he'll be happy to help if any of you have time to. Okay. Uh, last one or last almost at the end. This RVA23 is um the latest ISA spec. As we said, Federra currently uses something called slightly older baseline and switch switching to RVA23 as a baseline is a big topic and we have to work out as a community. So we don't yet have a concrete answer. we're still um exploring because you need a good reference platform at least a couple of machines that are based on the latest I suspect RVA23 if they're out in the market then you can you can um decide we can decide what because Federa tries to do it the right way so we we don't want to rush and we want to be thoughtful about it so that's uh an in progress work so if you're interested in this topic come talk to us on the metrics channel and what about the ecosystem readiness in in in terms the software how is Linux ecosystem doing on that there is a whole talk by Andrew Jones from colcom um he also chairs the hypervisor special interest group in the ISA so he gave a talk a very good talk on this topic so I recommend you to check out if you're interested in the details um kernel is one quick word as um it's there the older um the older SOS will support the RV23 kernels because that they are subset of the RVA23 ISA the older RV 64GC user space. So all of these details and more uh you can um learn in andrew's talk. [snorts] At the bottom I mentioned one more um system call. It's a it it lets you detect reliably detect risk five extensions in the Linux kernel. Um and this was recently in development and again details of this are in the documentation kernel. If you're interested in this, if you're a user space developer, want to understand what this is, check that out. That's pretty much it. So over there, um last this call uh for uh volunteers getting involved. So what kind of things? Test the omni kernels if you can. If you have a board, try to boot the images that we're producing. Um there's one more thing I wanted to put a plug. If you are interested in porting some software to risk five open source software and your employer is already not a member of risk 5 international there are some funds available to do the porting. So rise initiative the risk 5 software ecosystem they have some funds um and how um to get those is all documented in the links over there. So it's you have to describe the project what you've done uh and it's often times it's not a lot um wiring up in the CI making sure um basic optimization is there and the example projects are also listed in the project scope link. So what kind of funding you get depends on that. Um, so check that out page. Uh, check that page out if you're interested in um, porting some riskfi software or doing some of the CI work or other larger for for if if it's a larger initiative. There are bigger funds, but it depends on what what is the scope of the project. Yeah, communication as I mentioned um, come talk to us and there's five metrics if you're interested. There's a forum, there's issues, so on and so forth. References, um, some links if you're interested. So I wrote a trip report for last uh risk 5 summit. So what's happening at the ISA conference so you can read some of those um and there's a ticket as I mentioned uh for risky inclusion in primary koji what are the details it's it's over there the first link that's the link for slides um that's all I've got if you have any questions comments rude remarks go for I don't think so. >> I'm going to repeat the question. >> Yeah, that's good. >> Okay. So, regarding the uh the Fedora build hardware, are you planning to go still to the K3 and then later on switch to the Atlance? Because at last will require I assume you will go with either um x86 general CPU and then put the accelerator card there or ARM and then you can use the builder for both architectures. >> The question is are we going to in federal builders are we going to switch to K3 and then to Atlantis? Is it well Atlantis is not here. So I' I'd rather I' I'd rather talk about things that is already here. I I always quote this Chinese saying I I love it's called talk does not cook rice. So I want to see the silicon. So talk does not cook silicon. Um until it's there we can't talk about it. So K3 yes we already have a machine in the in the risk 5 koji and another is on its way. So um yeah we eventual plan is if there is a capable machine that comes we we have budget planned for it. So we'll we'll put them in the data center to get get it going. >> Okay. Uh second question since you've seen way more hardware than than I did and I know that there is lots of work going with the shim for secure boot have you seen any board already that now has secure boot framework frameware implementations yet? >> Not that I know of. No secure boot is an evolving topic. I think um we have a bootloader specialist in the room if um if you if you want to talk. >> Um so not yet. No ma you want to have a comment? You have a comment? Okay. >> Hey, so assuming that the K3 hardware was the thing you could put in right now and make builders from, how many of the patches set would you are needed to enable those right now if that was what we were doing? >> How many of the what? Sorry. >> Uh the the kernel patches that you're carrying in the Omni kernel. How many of those patches are actually necessary if we were going to use the K3 uh hardware to spin up Koji Builders? Are you talking I'm assuming two all those 200 are mostly hardware peripheral device patches? How many would we need to carry just to spin up an unmodified Koji Fedora builder if you were to put the hardware in place today? >> Right. I don't know top of my head how many are required. I think that those 200 patches are all not only for K3 by the way. I >> was saying what what what is needed for K3. What would we have to carry today? >> I think the things that are not merged yet upstream I don't know the top of my head what are the peripherals and low-level component patches that are merged and what are in flight. So we can I can I can ask Jason to to uh discuss. But it would be good because if if you're if you're thinking about K3 being the thing, I we need to have a discussion of what what minimum viable patch set is. Yes. And have that discussion with Forbes. >> Yes. >> Um because because if that's what gets us to Koji Builders so that we can we're not stuck too long there, then we should be able to have that discussion. But we need to know how many patch sets that are, especially because these are really aren't going to go out to users yet. It's just for internal enablement. So we can start doing the things so that we can get things to users when everything is upstreamed right it's no different than what we're doing with secure boot or fix right we have to have that discussion and we know what the number is >> right we don't know right we don't know if K3 will be the thing but it is yeah right now but right now that's the machine we're working with and we'll slowly get there and and also these builders are not in federal DC so these are maintained by community maintainers so that's one of the path towards the primary architecture or primary include primary built system is to have this hardware in Federal CO data centers. So that's for that um I think and early Q1 2027 more light should clear up Atlantis from Tenstor might show up again once it shows up you also have to hook it up into the DC get it wired up and so on. So yes, this a conversation to be continued. But if you're interested more in how many are necessary patches, I think Jason will know top of his head his arc repo has the has the details and I was also discussing with Jason uh Justin I keep calling Jason Justin mixing both names Justin Forbes um our federal maintainer so he's open to work um obviously with whatever that can be upstreamed. So we're working with the car kernel maintainers as well. >> Okay. So related to this uh topic, spacemate is the uh designer of the uh K3 boards and they do have a GitHub page with all the peripherals and their state upstream. >> Yes, I actually I linked it at the bottom of the slide there. So there is a wiki page. I know what you're referring to. it is linked in the in the slide that I mentioned um about K3's hardware at the bottom of it. >> So the status from my point of view the status of K3 is quite good. >> Yes, >> they are working really hard on getting everything upstream compared to K1 which I is the board I was working with. This is way better. >> Yes, we're in touch with the hardware vendors. They're also responsive if you have any issues. They're they're always um willing to help. So that's the kind of um software hardware vendor collaboration you need. So yes, you're right. >> Yeah. And now a question of my own uh related to the benchmarks. Which uh kernel were you using? Was this some burn kernel Linux mainline? >> No. Good question. So um the the host was running space own vendor kernel. It has some patches in there. But all these benchmarks um I was running in a Federa container on. So I wanted to keep as close be as close as possible to federal user space and it's it's running a it's called a bianu and their their kernel but um yeah it's it's spacemates kernel it's not not the mainline kernel but yes it's it's the user space is federal user space all of it anymore is the k3 speed acceptable for the users % rollings because it means at least mass rebuilds taking two or three times longer or will you be waiting for the uh next generation? >> So the question is is K3 enough for regular federal packages? Yes and no. Uh it for most yeah for most packages it's okay if you're doing the builds if I it's yes the answer is yes I would say um it's enough if you're a developer packager um wanting to make sure your package works well it's optimized well I think I would recommend to to get it and even the omni kernel boots on it so you can um get it um and test your stuff on on this >> yeah I mean more speed because if we will be doing the master build for the next federal with uh Primary architecture risk five it will take a long lot of time. Was this discussed somewhere? >> Can you say again please? >> The speed itself the master build will take two or three more times than the current one. >> Yes. I don't know top of my head like how how how long it will take but it will it will still there will still be some delay depending on what issues show up. So each each each master rebuild uh there's a new tool chain issue we didn't anticipate right. So you you know how it goes in federal land if you're involved in it for a while. So it just can anticipate them and have to work with the right maintainers and solve them and go on. and it creates a delay because when you're not in the primary cooji and it's not blocking so you're the lag is there but um so far from what we're seeing we it it does provide meaningful um bench performance improvement but David did point out the day before my co-speaker um some packages have slight degradation but this is more like an exception I think I didn't do like a tero analysis um you can come to the metric channel to to to understand if you want to see what that is. But um most of the like the the big packages as I was pointing out the kernel, GCC, gypsy, OVM this kind of stuff we do see meaningful improvement. >> Okay, maybe the second question now uh you have mentioned that you have that separate disc get uh how many packages have the specific patches there? Not a lot actually about 110 or if you lick click on the Federal Ris tracker um you will see the list of them. I can give you the link to that if you scan the code QR code you can see the list already on the Federal Ris tracker. Um this one yeah tracker. Yeah, this one. Andrea has it on his page but several people are pushing to it. Marcine especially is doing a lot of uh updating of it. So um you can see that the list there. It's about 100 120 or something like that. So, if you want to help with any of that, you're more than welcome. Any more >> any more questions? >> Okay, I think we're good. >> Thank you. Thank you. [applause]