RT Linux Patches

sally bitter writes "Linux 2.6 kernel Real-Time? It is going to happen soon. Montavista developers submitted patches today to LKML to begin testing all the low latency task preempt and interrupt stuffs they're introducing."

When will these be merged?

[Adam Avangelist]

Do you all think these will be merged and ready before 2.6.9 is released?

Re:When will these be merged?

[Anonymous Coward]

When it's tested, and works. And when Al Viro are done with
his rants over the code.
My bets are by 2.6.18, any takers ?

Re:Good news, folks

[WillerZ]

On a serious note, the design decisions for a general-purpose desktop/server OS are very different than for a safety-critical embedded system like an ECU. There is often no reason to have a pre-emptive multitasking OS in application-specific systems, as they only do one thing.

There are embedded OSs for which every line of code has been checked and audited. I think that's a good thing where lives are at stake. For Linux to meet those requirements would require a massive slow-down to the development effort, which would reduce how useful it is as a desktop platform.

Phil

Re:Good news, folks

[WillerZ]

...there's very little to go wrong.

"very little" is more than I want to be going wrong in my car at 70MPH. Phil

they can dream

[quelrods]

Linux is a monolithic kernel. To be an rtos you usually start with a microkernel: Qnx, VxWorks, Hurd. In order to turn linux into an rtos they would have to rework it from the ground up. In addition they would have to completely break backward compatability. A popular RTOS that can be consumed by the masses would be nice. It would allowing upgrading the OS without rebooting, guaranteed processor time, nearly instant booting, better security, better reliability, and tons more. All the patches appear to do is attempt to get linux to pre-emtively multitask correctly. This by no means will make linux a real time os.

Re:Good news, folks

[WillerZ]

Not necessarily. Those aren't the only two choices: Realtime Solaris and QNX RTOS are also possibilities. Even better, they could stop trying to add DVD players to my engine-management unit. I don't feel there's anything compelling missing from my current car, which has a number of separate systems and a fairly simple (so far as I can tell) EMU which co-ordinates their efforts,

The linux (kernel.org) codebase is not really stable enough to meet the needs of embedded systems. If someone wants to build an embedded controller for a car they'll need a stable embedded OS for at least 9 months before they start production -- 6 months to write the software and testcases, and 3 months to test and debug at a minimum. During this time, there is no benefit to selecting linux -- you aren't getting the new features because you've frozen the kernel; however, there is a downside to selecting linux -- bugs which surface later (perhaps in the testing phase) will not be fixed in the form of a patch to your level.

That suggests you need to buy your linux embedded from a commercial venture, to ensure it's supported. At which point, linux needs to be judged against the commercial competition; it will probably lose that battle because the commercial ones will be certified compliant to a myriad standards, and linux won't be. Certification is important to establish a chain-of-blame should anything go wrong.

Phil

Re:Good news, folks

[WillerZ]

I agree. It would probably now be easier for a company with an existing RTOS which is massively out-of-date to dump that and fix-up linux, rather than develop their own product further. New entries to the market will still find it very difficult as the path to certification is painful if you haven't trodden it before.

I hope this happens, as a lot of the work they would need to do to get certified would benefit desktop linux, particularly in the realm of hardcore POSIX conformance.

Phil

Re:So what is the verdict?

[0x0d0a]

Are there any benefits for the senior noob who can patch and compile the kernel with the RT features.

No. Real time functionality is not just "better latency". Real time stuff is generally significantly less efficient than traditional schedulers. It's useful for specialized work -- this is not "better desktop" or "better server" for anything approaching the typical Linux end user.

If you're doing control work with Linux, then you might be interested.

Re:Time to be a troll

[0x0d0a]

Your system will be slower, but will feel more responsive.

You do not need a real time system to "feel more responsive". In most systems, kernel locks simly do not tie things up for anything approaching human-perceptable times.

This stuff is important not for the server or the desktop, but things like control systems.

Re:Time to be a troll

[ClosedSource]

"They do this by modifying the kernel source to make sure program ISR's get called within a set threshold. For example FSMLab's RTLinux has a worst case response rate of 12 microseconds."

Although you described real-time issues correctly in most of your post this paragraph implies something that is not true of real-time. Real-time is not about being fast, it's about being consistent.

In the toughest real-time situation, the important thing would not be that the response rate is 12 microseconds vs. 12 msec, but that it is exactly 12 microseconds or 12 msec within the resolution of the system. (Obviously the system speed has to be fast enough to meet minimum timing requirements, but that's a speed issue, not a real-time one.)

The easy test to determine if a particular system has hard real-time requirements is to ask yourself if speeding up the system will solve all the problems. If it does, it's simply a performance issue, if not, it's a real-time issue.