Re: Xenomai 3.1 application compatibility with newer kernels
Jan Kiszka <[email protected]>
| Newsgroups | dev.linux.lists.xenomai |
|---|---|
| Message-ID | <[email protected]> |
On 05.03.26 18:33, davide gandolfi wrote: > Dear community, > > I have an application (a library) that is linked against Xenomai 3.1 (I bet using the Posix skin), and runs fine with kernel 4.19.114-cip24. In particular, it uses RtNet drivers. > Now I need to update the hardware, and most solutions on the market have newer cpus not supported by that kernel. What are my best options? > > On the ipipe-x86 repository, I see that kernel 5.4 is supported, but it is not clear to me if Xenomai 3.1 supports it. We stopped testing against 5.4, but 3.1 used to support it. > Moreover, 5.4 is still too old for Alder Lake or newer processors. > Then, we have the dovetail repository, which is the most updated, but I think it does not fit with Xenomai 3.1, am I correct? Correct, you need 3.2 at least for dovetail-based kernels. > Lastly, I could update Xenomai to 3.3.x and use the latest dovetail kernel. This is what I did and the system works fine with basic tests (like "latency"), but works horribly with my old library. > In particular, I have several spurious relaxes and mode switches on the thread that, I guess, is responsible of calling the RtNet driver (not 100% sure on that because the library is closed source). You can use system-level tracing (trace-cmd & Co.) to understand at least from the kernel perspective what is going on, e.g. which syscalls are issued or what other reasons there are for relaxes. > > What are your thoughts? Is it expected that the API, in particular for RtNet, changed from Xenomai 3.1 to 3.3? Please note that I don't have any segmentation fault or crash, the application seems to work fine, just not "realtime". Shall I expect better compatibility if using Xenomai 3.2 or it is not worth trying? I would not expect the issue in RTnet, specifically as that code barely changed in the past releases. But let's collect the real reasons first (see above) before speculating about them further. Jan -- Siemens AG, Foundational Technologies Linux Expert Center