Hi Dan,

roughly speaking, only the kernel has a 'real' interrupt
service routine attached, so every interrupt will first 
invoke the kernel. The latter will determine and mask 
the IRQ, call every user-ISR attached with InterruptAttach()
and deliver all attached interrupt events, and will finally 
signal an EOI to the PIC.

[The code for determining/masking the IRQ, as well as that
 for unmasking and signalling EOI, is board-dependant and 
 may be part of the BSP.]

The interrupt routines attached by drivers and other programs
are actually just callback-like subroutines which are invoked 
from kernel space. This has some consequences:
 - you must be careful when programming interrupt handlers -- 
   the stack is not yours, but the kernel's, and it's pretty 
   limited. Your static and heap data will be freely accessible, 
   though.
 - the kernel is already running, so you cannot enter it again 
   (i.e., do any kernel call).
 - being called from within the kernel, your code is run with 
   the highest available privileges (e.g., ring0 on an x86 box).

Hope this helps and I didn't forget anything important...

- Thomas Haupt

> -----Ursprungliche Nachricht-----
> Von: Daniel Rodrick [mailto:daniel.rodrick@gmail.com]
> Gesendet: 14 June 2008 04:12
> An: ostech-core_os
> Betreff: Interrupt service routine in userland?
> 
> 
> Hi,
> 
> Being a newbie, I have a high-level question about QNX. Since 
> QNX is a micro-kernel, thus all the drivers are nothing more 
> than high priority user space application. This means that 
> all the driver code is executing in user space, right?
> 
> Then how are interrupts being handled by drivers? I mean the 
> top-half of the interrupts (acknowledge the irq to device 
> etc) needs to be done real quick. How can the Interrupt 
> Service Routine code execute in user space? Or does it run in 
> kernel space?
> 
> Please enlighten,
> 
> Dan
> 
> _______________________________________________
> OSTech
> http://community.qnx.com/sf/go/post9151
> 
> 

I would suggest taking a look at the InterruptAttach() and InterruptAttachEvent() functions.

InterruptAttach() attaches a "real" isr which runs in the kernel, and does the "top-half" work that you mention (like 
checking if the interrupt source is yours, in the case of shared interrupts).  This ISR can then return a sigevent 
structure, which the kernel will use to notify a userland thread.  You can then do the bulk of the interrupt processing 
in the userland thread. 

InterruptAttachEvent() just passes a sigevent to the kernel, which it then uses to notify a thread of yours.  The kernel
 does the communication with the PIC (ID, EOI, masking).  Everything else is done by your userspace thread.  You have to
 be sure to call InterruptUnmask() in your thread, when you want that interrupt source to be unmasked.


Advantages of InterruptAttach() is that the ISR runs with the highest privilege level, which is required in specific 
cases, also if you have a system with shared interrupts the ISR can filter out interrupts which aren't from  your device
, so that your userspace thread isn't woken up unnecessarily.

Advantages of InterruptAttachEvent() are that you save an address-space switch, and all of the interrupt processing is 
in userspace, so you're not limited in what functions are safe to call.