>1. they added yet another kind of interrupt, which they called "adaptive"
>
> We added yet another kind of interrupt because that was the least
> intrusive way to make the patch. As I explained, if this were to be
> officially adopted, it would *REDUCE* the number of kinds of interrupts
> from two to one.
Yes, but the underlying implementation meant that at least initially,
there were *three* sets of interrupt entry and exit points. The ideal
patch would have had a single set of interrupt entry and exit points,
which were generally enough to handle either fast, slow, or adaptive
interrupts. (Where fast and slow means that instead of comparing
against the return value of the interrupt, you compare against
irqaction->flags.) Ingo suggested basically this as well.
2. hard-coded comparisons to see if the IP was the serial interrupt
> handler, and other really, really unclean stuff.....
>
> You're talking about the patch to diagnose serial overruns, which is
> totally unrelated to this thread of discussion, so why bring it up?
>
Uh.... because the patch that I looked at (that was on your web page)
had the diagnostic stuff tangled in amongst all of the changes to speed
up the serial port latency? It wasn't documented; it wasn't set off by
#ifdef's. In short, it was all jumbled together.
Again, Stuart, I'm sorry if I came across as being overly harsh. Your
fundamental ideas were quite good; we have some differences about the
qualty of your implementation efforts, but that's always something that
can be cleaned up later to meet higher standards of implementation and
architectural cleanliness.
- Ted