Linux

Back in the early aughts, QNX was making their flagship QNX 6 RTOS available for free for x86 developers. They were already quite successful with QNX 4 in medical and other mission critical equipment, and QNX 6 came with some very interesting innovations.

It ran a microkernel that did almost nothing but scheduling and message passing. Drivers were all in user space. Their Photon X server had a micro kernel architecture as well, so you could shutdown parts of it (or device drivers, for that matter) and bring them back up through the command line. You could of course set up watchdogs and automate restarts of anything but the microkernel itself.

I had some fun with it with and old and failing 486.

Been ages since I had to recompile a Linux kernel to deal with hard real time (via RTAI) but I recall emc2 being a great alternative to all the fussing around recompiling as some one did all the work for that.

I also recall using this resource . Eventually I just made a class for the threads I was using to wrap POSIX and RTAI calls for periodic tasks and chose which was the underlying method on a compiler flag. If I was on my desktop I could proof of concept most things in POSIX and then test on the RTAI machine. If I need to revisit this again I may dust off my old class and add freeRTOS stuff to it so I can prototype on Linux then try to squeeze it on to an esp32.

I remember hearing about this in the context of space missions, Linux just isn't a good fit for critical systems

I've been working on that exact problem for the last couple weeks. My solution for now is rt patch and a dedicated cpu core for rt tasks. This already works pretty reliable, but I notice small delays from time to time. I gather from the article that my problem might be page swapping. I don't know how to improve that, yet.

Also for anybody working on rt problems: I highly recommend the stress-ng tool for stress testing and finding bottlenecks of your system.