 Hello everyone, hope you can hear me fine. So I'm not missing any questions here. Good, so my name is Jan Kisker. I'm working for Siemens. You may have seen some talk of mine in the past already and I'm hoping to take your questions. I'm seeing there's the first one. So yeah, I'm taking the first question here. It's about real-time Linux. Here, one of my pet projects. I'm building it here for various reasons. And one of them actually is Xenomai, which I took over as a maintainer, oh, I think two years ago already. And the question was, if preempt that even is going to be mainline soon, will obsolete Xenomai? This is a long thing to answer in the nutshell. That's basically why we are working on it. We don't think it's obsolete. There are different use cases for different real-time solutions. And we have solutions where we need Xenomai and we have solutions that we need preempt.t. And one of the key points we see for Xenomai is that we are flexible in modeling also real-time systems which are not politics compliant. Another advantage is the clear separation between the real-time and the non-real-time world or the Linux world, or what you call it. But of course, there are also downsides and that's obviously in the separate maintenance of a kernel patch. So in a nutshell, I don't see that there's going to be obsolete soon. Yeah, there's another question in this direction. So he is asking if how we see Xenomai in the context of EVL. So maybe for those of you who don't follow this, what is EVL? EVL is the next real-time Linux co-kernel approach written by the former Xenomai maintainer and Philipp Zerum. So he was starting a new real-time co-kernel approach for the kernel, which has some similarity with Xenomai from a further distance, but has a new kernel patch. I don't see that this is, well, obsolete in one or the other, definitely. So it's an interesting approach to have a clean rewritten technology. And we are trying to make use of this. So there's actually currently ongoing activity together with contributors among them from Intel to port Xenomai over the foundation of EVL, the Doftail patch. So we will try to make the best of both and combine them, having existing Xenomai users ported over in this way and making use of this new architecture and the new benefits of the new architecture. So Drew is asking regarding how we can decide between using iPype and when just native kernel in Xenomai 3. So there are two options with Xenomai, actually. We can run also on a standard kernel or normally on a primed RT kernel. That is, the use case for that is emulating APIs as I said, which are not POSIX compliant, provided internally Xenomai can map them on the POSIX APIs that we have in user space available. So a criteria obviously is that you are fine with the APIs available there and their properties. They can't emulate all the behaviors of pre-existing real time operating system or older operating system. So this is the limitation obviously of not having a full control over the scheduler and all the extensions that we've made with the kernel approach. So otherwise, I would say if you don't have a need for these APIs, you can also go directly for primed RT and not use Xenomai at all. So the Xenomai user space approach is for the case where you really want to have make use of specific APIs. So let's see, next question is again regarding EVL. So saying is that EVL should be much easier to new hardware. There's as I said, EVL and an adaptable kernel patch is a rewrite making certain things easier and cleaner. However, it's still a new project and we will have to see how maintenance works in the end. There's a lot of similarity in the problems you have to solve that we had to solve in the past and we still have to solve in the future. If adapting to new hardware is actually going to be easier with the EVL approach is something, well, the jury is open for, we will see how this actually will work out. I have some, yeah, I see some benefits in certain things that EVL is doing. I also see some things which have to be solved again, like providing a real-time driver API because we have a different scheduler, we need a different API separate from the mainline kernel and that basically makes hardware adoptions also needed by the drivers and that may actually result in similar but in the end still same porting and maintenance efforts. So we will see, I mean, ongoing activity is there and we will have to compare the outcomes with what we are doing so far, which is also not optimal and yeah, then see how it evolves. So, next question. Staying here in the context, Drew. There are rule of thumbs for different ranges of latency and the solution on, let's say, modern ARM SOC something like 10 milliseconds to one millisecond, normal kernels, 10 milliseconds to 100 microseconds, pre-empty 100 to 10 microseconds, I pipe under 10 microseconds. Well, obviously this depends on this kind of scaling what hardware you're running on. So if you're running on a very low end, almost below one gigahertz processor, which still exists, this range is obviously shift. Xenomite does have a little bit of advantage in certain scenarios on certain architectures or performance professors over print at T. A little bit, I wouldn't say it's factors of magnitude or orders of magnitude, but if this is really your key question depends on the use case, I would not only make it on the latency scale of other look and other aspects as well before choosing print at T over Xenomite. So let's look for a different question. So Devon asks, Debbie seems to be more advanced than LB ESA. Why not switch and stop both? So, first of all, these are different approaches. Debbie uses the approach to recompile a Yocto-like system or E-like system from source code which is not provided from the upstream project, but rather taken from the Debian packages. That's the primary approach there. Elba and ESA both built upon primarily the binary packages as they are provided by the Debian project. So the difference is already in that detail. That means that you can easily use with LB ESA binary feeds from Debian upstream and also from other sources of Debian compatibility. While Debian itself is not compatible in all cases with the structure and the format of the original Debian packages, it's more compatible to the Yocto package structures and system structure. So this is a major difference and what you prefer depends on your use cases of the scenario. You can strip systems more down with Debbie than you can do with a Debian compatible approach. But there's an area where both fit well and there's an area definitely if you come to complex, higher complex systems where you benefit from having most of the system already integrated by Debian and the community behind it and not having to remodel the packages. You know, I'm not switching too much to topics. That's the next questions are we again, we're going to talk a little bit about Xenomai related. So I'm gonna ask and notice the Xenomai latency is higher when running on a system with UI. Where does this probably come from? So normally that the problem comes not from interrupt management or something specific to the graphic driver. Well, there are might be graphic drivers which have a long interrupt off latency paths. Although that was Xenomai should be broken up. Normally the higher latency comes from hardware effects that you have shared resources in the hardware that you cannot easily manage in software. And these shared resources basically block or delay your real-time work even if it's just CPU bound and not have anything to do with the UI. That's the rule of thumb, generally the reason for having higher latencies with UI systems are active. But again, it depends heavily on the architecture and things used there. So I do ask about use case, audio processing for real-time system. So there's bella audio using Xenomai I pipe because they need worst case latency which are one of my 90 microseconds and below on a Cortex-A processor. So do you think this could be achieved with preempt RT? Well, 90 microseconds on this, that's a TI sitara processor, AM3, that's definitely in the range of the architecture of what the hardware can deliver. These systems to my experience are likely noteworthy faster with a co-carnal approach than with preempt RT. Although I have personally never tuned preempt RT on any of this system and can talk with this can actually be improved. But this is actually the area when your workload is close to what the hardware can deliver with a reasonable software stack. And Xenomai helps you to get over this and preempt RT basically is too close to the border or actually violates the border. Then you are better off with a co-carnal approach with something like Xenomai. This is definitely a good case where performance come into play. But normally if you are close to the limit, you may have to trust the system so much that it's probably not a good idea to only rely on the software approach and think about also other alternatives and ways to avoid that you are too close to the border. Oh, hi, Tim. Tim Bird asks, app-streaming status of preempt RT. App-streaming status of preempt RT. So CIP is currently managing two kernels for the long-term support RT non-RT. Will they be able to up to a single kernel per release in the future? Yeah, I really, we are counting on this. This is also the reason why we are supporting the real-time project that we only have to support one kernel in the future. Unfortunately, this won't be something coming soon like 5.10, so probably another year. My feeling is that year would be great and the probability is likely higher, but it's not said that it's going to be even by the end of next year of having then everything in mainline. For CIP, if we follow a cadence of having every two-year new kernel, though this is not officially announced, so this is still something we are discussing, the next but one kernel might be an option for us to pick up pre-empt RT from upstream. That would be great. So I'm optimistic that the next or next but one kernel of CIP will then have also RT in the same code base, yeah. So let's see, there's another new guy on the list. The question is, can I get more information on real-time Linux topic? Yeah, obviously, but I guess this will blow up the talk if I provide it here. So there's great information around the real-time Linux project. So if you look there, I don't have the URL here handy, but if you look for the preempt RT projects and their resources, there's a lot of information for beginners. Obviously, also the core kernel approach like Xenoma and EVL have project documentation around it, although some information might be aging. This is a general thing, but these are good starting points to look for specifically. And I think there was a talk these days also about how to write rhythm application all over preempt RT is also a good starting point. That could be a good start to get started and look into how to set up those systems and play with applications. So, okay, this is one question. So RT, Xenoma operative RT on USB is of no avail, huh? Okay, so real-time over USB, this is actually a quite old project of mine started together with back then a student at university times and we actually made it work to a certain degree with USB one and USB two later on. So basically we wrote a core host controller driver for that time for Xenomai to drive certain USB attached camera sensors devices in a way that is more predictable than you go with normal USB stacks. So technically it's possible. I remember that we run into a lot of fun effects. I mean, USB is in some details not completely deterministic and you of course also depend on the end device. So yeah, it's doable. I wouldn't say it's something which can become commodity. And yeah, it's definitely way harder to change this in the mainline kernel if you wanna do that simply because the whole USB stack is not designed around real-time scenarios. So I hope I can have answered both of these. Oops, oh yeah, I clicked too many. So I think Tim, I just, I guess I deleted your question. Maybe you can bring it up again. Oh yeah, Frank noticed that there's also the information of course in the edinux.org wiki about real-time. So it's also something important to notice. And yeah, the good old real-time Linux workshops they also have a lot of presentations and introductions. So I hope I find, yep, we had this on edinux.org. You find a lot of information, not only on real-time Linux actually in general. So worthwhile to look at. So Drew, maybe you can bring back the context. The problem is I'm only seeing the unanswered question here. What are you talking about regarding Summit on Friday? There's a Summit on CIP on Friday. What Summit do you mean? So there's a new question regarding what's the status of security isolation in embedded virtualization plans for next year? Security isolation, this is a general question. So I'm not sure if you're asking about a specific project because there are many things, many hypervisor project in the embedded space and many of them targeting all security scenarios. So look around, the ecosystem is full of them. Even the open source ecosystem, there's something like Xen, Acron, people use KVM. There's a JLOS hypervisor that I'm kind of involved with. So there is a broad range of this. So maybe you can be more specific in your question and I can kind of follow up on that. Yeah, all right, Drew, so there is the real-time Summit on Friday, right? Yes, indeed. So there's a question if Xenomite could become possibly an official project for Linux Foundation. I wouldn't exclude this, definitely, and having a home for the project in a foundation might be an option. In general, the point is it takes critical mass, so companies move forward and push it there. I'm not a fan of if, for example, we currently, as Siemens, driving the project would just say, okay, let's put it on the Linux Foundation alone. So that would take at least a second partner, ideally, a Linux Foundation member or active in this direction to move the project forward. So definitely Xenomite, even if I'm maintaining now is not a Siemens thing, it hasn't been, and it will not be. So yeah, putting it on the Foundation helps or can help to make this clearer. It can definitely help to raise certain visibility, but in the end, it still also depends on companies moving forward and getting active also on the code. And in this regard, I really welcome recent contributions, not only of Intel, but also of them. There are many people now working actively on Xenomite, and it used to be, so it's good to see that this is moving forward and you'll see what comes out of this. So we adjust again the pointer to the real-time summit, so people can see this, maybe better in the chat than here in the question list on Friday. So let's see if I'm still, might not be online anymore, I see. It's 10 past five here, so I might be the session might be over. So in any case, I can continue the chat here as long as it's possible, but it may not be broadcasted anymore. So Francois says that Power 11 has apparently noisy neighbor protection. Any plans to put it in jailhouse? Well, so first of all, it would mean putting jailhouse to power. Actually, we do not really have that much use cases here around inside regarding power architecture. It used to be some, but no longer. So yeah, if someone is interested in bringing this forward, I wouldn't reject a power port. So for example, we are currently working on risk five ports, but this is probably something that we wouldn't drive, but yeah, the community is open for these kinds of contributions. But in fact, noisy neighbor protection is something which is not only a Power 11 architecture, there are other architectures also providing this to the different degrees being adopted. Okay, so yeah. Thanks, I'm done. Thank you organizers for making this possible. I hope I could address most of the questions. So if you wanna reach out to me, just use the chat afterwards, I'm around here. With that, thank you. Bye-bye.