Re: [patch] IRQ threads

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

On Wed, 2004-07-28 at 11:45, Karim Yaghmour wrote:
> Scott Wood wrote:
> > I have attached a patch for implementing IRQ handlers in threads, for
> > latency-reduction purposes.  It requires that softirqs must be run in
> > threads (or else they could end up running inside the IRQ threads,
> > which will at the very least trigger bugs due to in_irq() being set). 
> > I've tested it with Ingo's voluntary-preempt J7 patch, and it should
> > work with the TimeSys softirq thread patch as well (though you might
> > get a conflict with the PF_IRQHANDLER definition; just merge them
> > into one).
> 
> My experience with clients who have been using TimeSys' stuff has been
> abysmal. The fact of the of the matter is that most people who used
> this were practically locked-in to TimeSys' services, unable to download
> anything "standard" off the net and using it with their kernel. In one
> example, we had to ditch the kernel the client got from TimeSys because
> we had spent 10+ hours trying to get LTT to work on it without any
> success whatsoever.
> 
> As I had said on other lists before, I don't see the point of creating
> that much complexity in the kernel in order to try to shave-off a little
> bit more off of the kernel's interrupt response time. The fact of the
> matter is that neither this patch nor most of the other patches suggested
> makes the kernel truely hard-rt. These patches only make the kernel
> respond "faster". If you really need hard-rt, then you should be using
> the Adeos nanokernel. With Adeos, you can even get a hard-rt driver
> without using RTAI or any of the other rt derivatives.
> 

This is obvious FUD from someone who is selling something.  Please keep
this crap off LKML.

Lee