Preparing for the realtime future

Yes, everybody wins. The continuous integration of the kernel developers on the one hand and the RT system engineering that we provide on the other hand are two different activities with a well defined handover. We start our work when a new RT kernel is available, compiles flawlessly and runs for a while with expected RT capabilities. But whether this kernel behaves as expected on a particular hardware and firmware combination in an industrial device over long periods of time is another matter. Skylake, for example, took us more than a year to get a suitable BIOS and to find out appropriate settings of BIOS variables. And even Apollo Lake that Intel equipped with special RT properties took us about six months to convince BIOS and board manufacturers to actually implement the recommended variables and let us select and configure them. Or take the RPi as another example. It didn't work with RT until OSADL took care of it and published a patch (https://www.osadl.org/Single-View.111+M5c03315dc57.0.html). You cannot expect this work to be done by the RT kernel developers, this is why you need OSADL.

We know that some of the imperfection of the current RT patches will only be solved after they will be completely merged to mainline, because this is the only way that subsystem maintainers can test their upgrade changes against RT early enough. Until then we try to do our best to support the merging activities and not to jeopardize them by submitting our "exotic errors". Instead we are searching for workarounds by not using certain configurations and functionalities. People may then use the configuration of the respective QA Farm system to create a state-of-the-art Linux RT kernel.

When some of the diagnostic and auxiliary functions that we need for our assessments but may require extra work to merge to mainline were thrown out of the official RT patches we decided to take over their maintenance (https://www.osadl.org/?id=2943).

A number of systems of our QA Farm run in so-called shadow mode. These are twin systems with identical hardware and software that are ideally suitable to test the effect of changing a single variable. We use these shadow systems often to study the effect of a particular setup on RT capabilities such as hyperthreading, graphical mode, various kernel configurations etc. and document the findings in technical assessments. Some of them have been made available to the LF Real Time Linux collaborative project on request.

In conclusion, there is nothing wrong with having separate organizations to take care of various stages and aspects of the RT patches in the interest of all of us. We are glad that users of the RT patches continue to join OSADL as members and help us grow and, thus, do even more and better for the Linux RT community.