I decided to sit through some competitor sessions today, the first session is Linux Real-Time (the presenter karim yaghmour was a few minutes late – real-time session, yep, on-time, nope – Karim is very knowledgeable about Linux development, and is the author of Building Embedded LINUX Systems).
Karim has written an article “Embedded Linux: Semantics and Reality” where he makes the following (somewhat startling) statement: Let’s put it bluntly: embedded Linux doesn’t exist. Embedded Linux is the stuff of glitzy announcements, hype, and other marketing mumbo jumbo. That is, at least, the conclusion I am forced to reach after having spent two years writing a book about the use of Linux in embedded systems.
The presentation started by stating that Linux is not suited to real-time development, and real-time Linux systems are tough to build. Big take away is that Linux is a soft-real-time O/S and you may get better results from operating systems that are built for embedded real-time development – Linux is designed as a desktop/server O/S – the scheduler and interrupt architecture doesn’t lend itself to real-time development, this is a general purpose operating system. Karim stated that any vendor that states they support “real-time” Linux needs to be checked carefully to determine exactly what’s meant by “real-time”.
Drivers can disable interrupts, therefore you’ve instantly taken a hit to determinism on the O/S, there’s no way to determine how long the interrupts will be disabled. Tasks can run as RT or RR (real-time, or round robin), an RT task can ‘hog’ the scheduler, if this happens then all other tasks are starved of cpu time, again non-deterministic.
There are a number of approaches, none of which appear to provide any level of determinism:
- **carefully** select O/S components, and cross fingers
- Low latency patch for 2.4 kernel – comments are “it’s overrated”, “it’s a placebo”, “it’s useless”
- High-resolution timers (reprograms system timer) – not implemented, Linus doesn’t like this approach – still doesn’t provide determinism
- Interrupt threading – based on FIFO, little documentation, untested
- Jiffy-less systems – allows for arbitrary reprogramming of the system timer, very early stages of development
- Dual Kernel – using a “real-time” kernel sitting along side the regular Linux Kernel.
- Interrupt prioritization – very hardware dependent, probably won’t catch on, too specific
- Nano-Kernel – run multiple operating systems side-by-side, mechanism for sharing interrupts – O/S cannot directly manipulate interrupts – Adeos is available as a kernel patch – requires special API calls from ALL components in the O/S
Take out – no single solution, many projects have been tried, none stands out as a real-life solution for embedded and real-time solutions. Karim mentioned that there are examples of shipping real-time Linux devices, all use their own specific implementation of real-time support.