The short answer is NO.

The long answer is that there's patchsets like linux-rt which give it better "soft realtime" behaviour, but no hard realtime (deadline guarantees), thus not actual realtime.

Linux-rt allows "coexistence" with "hard realtime", but it's basically a cop-out: Just reserve a processor to run something else than Linux for hard realtime tasks.

In reality, while linux-rt patchset (not mainline) suffices for most pro audio work, Linux has over a million LoC of trusted code base running in supervisor mode; It should not go anywhere near where anything requiring any kind of assurance is running. This happens to be the case with tasks requiring hard (i.e. actual) realtime, as hard realtime is all about guarantees.

My advice for hard realtime would be to look at seL4 and eChronos, both open source as per OSI definition, and pick the one best suited to your design.

For some use cases, a Beaglebone black can allow for "real" real time while running Linux. It has two microcontrollers (PRU) that share memory with the main ARM cores. So if the real time part can be satisfied by the PRU, it's a neat solution.

Same idea as linux-rt "hard realtime": Reserve a processor (doesn't matter if it's the same chip or architecture or not).

The issue with this is precisely the shared memory. If Linux can interfere with the PRU, then there's no assurance. This breaks hard realtime: No assurance that the system will react timely in a certain way to a certain event.

It does work well enough to, for example, drive large LED display boards, emulate old video cards, processing audio, etc. Things that don't work well with traditional soft rt-linux. I'm sure, as you say, that it isn't good for all use cases.

Yes, it has its uses but ultimately it is not hard realtime.

Hard realtime is all about guaranteeing deadlines. If Linux (which is not and will never be high assurance due to its TCB size) can interfere with guaranteeing deadlines, then it's only soft realtime.

There are patchsets out there that add realtime capabilities to the kernel. But as far as I know none of them is in the mainline. I am also not confident that the kernel can be made truly hard realtime capable without major rewrites. The best bet is probably RTLinux which runs the entire Linux kernel as one of the processes managed by a hard realtime kernel.

Linux isolated through virtualization under a microkernel is the way to go if running Linux in the same hardware is actually needed at all. The realtime tasks would simply run outside of Linux, shielded from Linux.

Genode's virtualization (particularly when paired with the excellent seL4 microkernel) is a good way to achieve that.

If Linux can interfere with the "hard realtime" task, then there can be no assurance (of meeting hard deadlines) and it's thus not a solution providing hard realtime.

Without any changes, you have SCHED_FIFO and SCHED_RR [1] schedulers, but despite the name, they are not really suitable for proper real-time tasks. Closest to real time on vanilla Linux is SCHED_FIFO task - as long as there is no other task with same or greater priority, your task don't yield, call syscalls or cause page fault, it won't be preempted. When it does yield (one way or the other), there are no guarantees when it's going to be rescheduled, which is severely limiting for considering it as RT.

[1] http://man7.org/linux/man-pages/man7/sched.7.html

Not at all, at it does not meet the realtime certifications for deployment into production, like for example ISO 26262.

https://en.wikipedia.org/wiki/ISO_26262

https://www.highintegritysystems.com/

One of the reasons why Linux is not suitable for real-time use is virtual memory. It's not even about swapping. The Translation Lookaside Buffer introduces too much variance into timing. Same thing with instruction and data caches and even instruction pipelining. It's not just Linux, but most general-purpose CPUs that are not suited for real-time control applications.

There is a patchset that enables deterministic behaviour on Linux (https://www.linux.com/news/event/elce/2017/2/inside-real-tim... has a few pointers). Much of it has been mainlined, and it does have trustworthy enough commercial backing that it's worth considering at least.

That being said, the more typical approach for this, as employed by e.g. RTLinux ( http://www.rtlinux.org/ -- I'm not endorsing it, it's just the one I'm more familiar with), is to run a hard RTOS along with Linux, running real-time tasks on the RTOS and everything else on Linux. It's a more complex solution, and it's a little unsettling that we've even had to come up with it, but it works surprisingly well. Writing fancy UIs and multimedia applications on top of things like QNX is difficult (not necessarily in terms of learning/development effort, but also in terms of licensing, cost, hardware support etc.), while writing real-time control applications on a patched Linux kernel requires some trips down the kernel rabbit holes, and is hard to get through some certification processes. Companies optimize for whatever they need :).

Absolutely.

https://rt.wiki.kernel.org/index.php/Main_Page

This is the wiki for the PREEMPT_RT patchset. Parts of this have been moving into mainline for years, bringing the regular kernel closer and closer to real-time. However, there are some real-time features that will never be appropriate for mainline, so you can get them through this patchset. Some of the "famous" kernel devs are also very active in PREEMPT-RT; it's as official as you can get short of being in the mainline kernel.

For lots of uses, the regular kernel is already realtime enough.

AIUI the plan is to merge the patchset itself into mainline to ease the maintenance burden, but to keep the changes that don't actually make sense for mainstream server use under a special config/#define flag, PREEMPT_RT_FULL or similar. It will then be up to users/distributors whether to enable it. I've only tried the current patchset casually, but IME, the throughput penalty is there but is barely perceptible for casual use, and the improved responsiveness due to kernel thread preemption and the priority inversion fix do make the system a lot more usable especially under load.

It's currently not possible to compile Linux to something that works with 64k RAM and similar amounts of flash like what you usually would find on a MCU.