Bill Studenmund <wrstuden@netbsd.org> writes:

> The design we're talking about is very strongly inspired by the
> Solaris model.

As I understand it, that model is highly optimized for bus-based
interrupt controllers and not particularly suitable for scaling to
large numbers of independent interrupt sources per processor.

> Given that the desire is to run the interrupt "thread" by borrowing the 
> context of the interrupted thread, we will have mostly the same thing as 
> now. It took me a while to figure this out.

It's the part that varies from "mostly" that concerns me. If it turns
out that the assumption of very low lock contention is wrong, the
cascading and convoying effect that results from contention will be
very difficult to bound in soft real time systems.

>> It may be more work to get there, but it's an incremental change from
>> the current NetBSD model, and drivers could be converted as needed,
>> rather than trying to get everything right in one fell swoop.
>
> The paragraph above actually is one selling point of what Andy's
> suggested so far. :-) For architectures (platforms) with a PIC, my
> understanding is the x86 change should be a model that can be
> cookie-cuttered around. There are issues with modal architectures
> (ones with a separate interrupt stack), so we aren't done yet. But
> we're getting there.

I think, as I said above, there are also issues with non-bus-like
architectures.

> Oh, I like the idea of keeping the top/bottom split. I don't want to
> be doing tons of work in an interrupt thread!

A wise man once told me that "if you're doing more work in interrupt
context than you can comfortably code in assembler in an afternoon,
you're doing too much work in interrupt context." ;)