Re: [ANNOUNCE] Linux 2.6 Real Time Kernel

[Lee Revell <rlrevell@joe-job.com>]

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