ESDEVCON – Day 2 – Linux Real Time.

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.

– Mike


Comments (4)

  1. This was very interesting, as I also think that Linux based devices used for embedded area often are not "Embedded Linux" but desktop Linux flavor just running on ARM or MIPS chips.

    I also remembered Windows CE, the old "deterministic ISR latency" issue, which have been solved by the release of Windows CE 3.0 Platform Builder.

    Then I made a quote on my Blog (in Japanese) – See above URL.