[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: [rtl] Q: when are linux interrupt handlers are invoked?



> 
> On Fri, May 08, 1998 at 04:36:51PM -0700, Jun Sun wrote:
> > 
> > The RTL white paper says :
> > 
> > 	In RT-Linux, all interrupts are initially handled by the Real-Time 
> > 	kernel and are passed to the Linux task only when there are no 
> > 	real-time tasks to run. 
> > 
> > However, the rt-linux code seems to suggest that interrupts are passed to
> > Linux before real-time tasks get a chance to run. Here is the reasoning :
> > 
> > 1. I assume assembly symbol "linux_IRQxx_interrupt" is the lowest-level
> >    interrupt handler for those interrupts that are not interested by
> >    any real-tasks.
> > 
> > 2. "linux_IRQxx_interrupt" sets a irq flag in SFREQ and will invoke 
> >    "S_IRET" if the soft interrupt is turned on in linux.
> > 
> > 3. "S_IRET" will call the the linux interrupt handler through "SFIDT" table.
> > 
> > I don't see anywhere RT tasks have a chance to execute before the linux 
> > interrupt handler is invoked.  It seems like RT tasks can be delayed 
> > by lengthy linux interrupt handlers.  
> > Is this right? Can someone either confirm this or point out what is 
> > wrong with the logic?
> 
> The hard interrupts  are re-enabled before the linux driver is called.
> 

Thanks for the clarification.

It turns out my reasoning is probably still wrong.  I saw that soft interrupt
is ALWAYS turned off if the current rt task is NOT linux.  This means
linux interrupt handlers WON'T be invoked if the current running rt task 
is NOT the "linux" task (which has the lowest priority).  So, in other words,
if there are RT tasks running, the linux interrupt handlers won't be 
invoked, and RT tasks won't be delayed by linux interrupt handlers..

Does this sound right?  Thanks in advance.

-- 
Jun Sun 
--- [rtl] ---
For more information on Real-Time Linux see:
http://rtlinux.cs.nmt.edu/