[ECOS] isr() and dsr() running environment?

[Nick Garnett]

<jameshq@liverpool.ac.uk> writes:

> Thanks a lot. 
> 
> How if DSR1() interrupted by ext_IRQ2, when ISR2( ) exit how does
> DSR1( ) resume?  as the flow diagram(is the following flow diagram
> correct?):
> 
> ext_IRQ1 --> ISR1() --> DSR1() --> interrupted by ext_IRQ2 --> ISR2()
> --> call interrupt_end() --> call pending DSRs but now DSR2 won't run
> here because DSR1 not finished yet. (right?)

Not quite. Since the scheduler lock is >1 here, unlock_inner() will
not even try to run DSRs.

> --> return from ext_IRQ1
> --> back to interrupted DSR1( ) and continues excution --> exit from
> DSR1( ) --> still in Cyg_Interrupt::call_pending_DSRs_inner(void)
> because DSR2 still not run --> run DSR2( ) --> finish DSR2( ) -->
> return from ext_IRQ1 VSR (e.g Sparc target it returns from the call to
> "hal_default_interrupt_vsr" when the time ext_IRQ1 happens.) 
>

Other than the minor point above that seems correct.

> 
> BTW if the ISR( ) runs with all interrupt masked (regardless interrupt
> priority) in the HAL(or vice versa), how can we ensure the device
> driver developed by other people still works properly? Maybe some
> other device driver developed by other people require higher priority
> interrupt enabled (or vice versa) during the time when processing the
> external device interrupt? Will this situation be possible? Thanks
> 

I cannot see any reason for a device driver to want higher priority
interrupts to be in a specific state. Any device driver that makes any
such assumptions is not portable.


-- 
Nick Garnett - eCos Kernel Architect
http://www.eCosCentric.com/

-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss