Messages in this thread | | | Subject | Re: [ANNOUNCE] Linux 2.6 Real Time Kernel | From | Lee Revell <> | Date | Sat, 09 Oct 2004 16:59:07 -0400 |
| |
On Sat, 2004-10-09 at 16:53, Karim Yaghmour wrote: > Lee Revell wrote: > > In theory, I think yes, if all IRQs on the system run in threads except > > the saw interrupt, and the RT task that controls the saw runs at a > > higher priority than all the IRQ threads. You can guarantee that other > > interrupts won't delay the saw, because the saw irq is the only thing on > > the system that runs in interrupt context. With the current VP > > implementation you are still bounded by the longest non-preemptible code > > path in the kernel AKA the longest time that a spinlock is held. > > Replacing most spinlocks with mutexes reduces this to less than 20 code > > paths according to Mvista, which then can be individually audited for > > RT-safeness. > > > > That being said, no way would I put my hand under the saw with the > > current implementation. But, unless I am missing something, it seems > > like this kind of determinism is possible with the Mvista design. > > It may be a question of taste, but even if that did work, which I am > not convinced of, it seems to me that it's awfully convoluted. > With the current interrupt pipeline mechanism part of Adeos, on > which RTAI and RTAI fusion are built, I can give you absolute hard-rt > deterministic guarantees while keeping the spinlocks intact, and not > having to check for the rt-safeness of any part of the kernel. You > just write the time-sensitive saw driver int handler in front of > Linux in the ipipe and you're done: 100% deterministic hard-rt, > regardless of the application load and the driver set.
True, there are probably too many "ifs" in my above statement for a saw or an airplane or a power plant. There does seem to be a gray area between soft and hard realtime, where either approach could be reasonable. For example the Mt. St. Helens example, where you could miss a sample and it would be really bad, but not kill anyone.
Lee
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |