(no subject)

Theodore Y. Ts'o (tytso@MIT.EDU)
Mon, 28 Apr 1997 22:10:26 -0400

I'm sorry if you felt that I was unfairly criticising your
code. However, it is nevertheless true that the code which you asked me
to look at would have never gone into the Linux kernel as-is. You don't
need to "get rid" of things, as much as you need to make patches which
don't break things by default. You can unify the fast vs. slow
interrupt handlers, while still keeping them (apparently) visible at the
kernel API level, and so that we don't need to fix all of the drivers
right from the start.

>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