Wind River, one of the world’s top embedded software providers, has acquired a real-time Linux distribution and patented hard-real-time technology from FSMLabs Inc. The acquisition will help Wind River penetrate new and emerging markets requiring extremely tight timing constraints, including the vast, emerging market for low-cost, single-core feature phones, according to the company.
Wind River Acquires Patented Real-Time Linux Technology
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
Basically, RTLinux is a more-or-less stock Linux kernel running on top of a specialized microkernel called RTCore. RTCore traps hardware interrupts, queuing and/or reordering them before passing them up to the Linux kernel. Linux doesn’t realize it’s not receiving hardware interrupts directly from the hardware.
This is necessary because Linux doesn’t implement the concept of interrupt priorities or nested interrupts. All hardware interrupts are treated equally, and interrupt handlers cannot be preempted by another interrupt. They are handled in the order in which they are received from the hardware interrupt controller, with no exceptions. This is a design consideration to accommodate several supported architectures that do not implement these concepts, x86 included.
If Linux handles interrupts on a first come first serve basis, then the only way to enforce various possibly dynamic interrupt priorities is by altering the order in which they “come.” And since an interrupt will always preempt the running process, the only way to let an ultra-important process finish is to delay the arrival of the interrupt. This is what RTCore does. It can’t make Linux support nested interrupts, but it can do everything else.
If RTLinux is in the red corner, Montavista is in the blue corner. Montavista solves the aforementioned issues directly within Linux. In other words, it supports interrupt priorities and nested interrupts whenever the hardware does. The modifications to the process management subsystem are relatively straightforward. Making the interrupt handlers for every driver in the Linux kernel reentrant–that is, safe to be preempted by a higher-priority interrupt–is not so easy. Sometimes an interrupt handler will have to block all interrupts during a critical section, but the ability to preempt interrupts at all is better than just reordering and delaying interrupts. Theoretically, Montavista’s solution is superior to RTLinux. But it isn’t patented. Sort of like that cancer drug.
Both implementations trade a huge amount of efficiency for this real-time response. Every few microseconds they get a clock interrupt from the hardware and run a dispatch routine, RTCore possibly dispatching an interrupt to Linux, and Montavista possibly dispatching a different task. These are usually constant-time, or O(1), operations, but they consume at least a hundred nanoseconds, probably more. In addition, when the dispatcher decides to actually dispatch something, the algorithm becomes O(N) at best. That takes a sizable chunk out of each 5 microsecond clock tick. You don’t get much work done on a real-time system, but you get it done almost exactly when you want it to be done.
Edited 2007-02-20 08:14
Hi,
Thanks for the very nice post – it’s more interesting than the original article to me 🙂
Just one minor point…
This is a design consideration to accommodate several supported architectures that do not implement these concepts, x86 included.
80×86 hardware actually does support interrupt priorities, with both the (older) PIC chips and the (newer) APICs.
With the PIC chips, the interrupt priorities are fixed and badly organised (from highest priority to lowest, the IRQs go in the following order 0, 1, 8, 9, 10, 11, 12, 13, 14, 15, 3, 4, 5, 6, 7) mostly due to the addition of the second PIC and the way the cascade between slave PIC and master PIC works (ancient history).
With APICs the interrupt priorities are fully programmable (in that an interrupt’s priority depends on the interrupt vector set by the OS).
Above a statement was made about the overhead of real-time Linux. I have measured myself the overhead of the PREEMPT_RT mode on two different CPU’s: an 800 MHz AMCC PowerPC 440GX and an AMD Athlon 64 3000+. For these CPU’s the overhead of the PREEMPT_RT mode on an idle system is about 0.9% and 0.2% respectively. The overhead for processing network traffic was around 10% on the PowerPC. Both numbers are significant but in my opinion certainly acceptable if you need low scheduling latency.
Sounds like Sirius and XM to me.
They needed to buy them to take them out of the market?
They needed to buy them to take them out of the market?
They needed to buy them to get into the market.
Wind River is seeing its business dry up and looking for ways to get into Linux. Their previous play fell apart when Intel sold xscale to Marvell. Something like this was expected.
Of course, there’s enough prior art on the RTLinux approach that the only thing keeping the patent alive is lack of a challenge.
FSMLabs… Flying Spaghetti Monster Labs? Gasp!
The blurb reads like a press release and not real information. I am not an investor and I do not care whether this company penetrates any new markets. Not one word is said about what real time linux is, what the hardware in question is or does or why I should care.