On Feb 21, 2007, at 12:08 AM, Matt Thomas wrote:

> After a great of pondering, I've concluded that interrupt threads  
> are an extremely bad idea.

Matt and I discussed this at length over lunch yesterday, and I am in  
full agreement with him on this.

The way I see it, interrupt threads are an attempt at solving the  
synchronization problem from the wrong direction.  Instead, I think  
the right approach is to fully split every driver into a "top  
half" (runs with thread context, possibly as a high-priority kernel  
thread) and "bottom half" (runs in interrupt context).

Furthermore, I believe that the bottom half should manipulate state  
that is local only to the instance of the driver associated with the  
device that is interrupting (and have that state be spin-mutex  
protected).

This approach would have a few advantages:

1- Simplicity.  Interrupt dispatch would be largely as it is today.

2- Speed.  Because the low-level interrupt dispatch code could be  
simple and avoid magic, it could be very fast, which would help  
devices that are particularly sensitive to interrupt latency.

3- Portability.  Because the low-level interrupt dispatch would work  
basically like it does today, we know it will work on all of our  
extant platforms.  I think there are some particularly nasty "gotchas"  
with interrupt-dispatch-as-continuation-or-thread that can be hard to  
fix on platforms like VAX (especially) or even SPARC and m68k.

4- Consistency.  We already have this sort of model "sort of" today;  
consider serial drivers that have hard-interrupt handlers that run at  
extremely high priority to read data into a local ring buffer and then  
schedule a soft interrupt to do the TTY processing.  What I'm looking  
for here is to formalize this for EVERY kind of device.  This will  
make it easier to write drivers for NetBSD.  We could even provide  
some API to help people write drivers that conform to the model.

-- thorpej