Paul.
--- /dev/null Mon Dec 31 23:00:00 1979
+++ linux-2.3.18ac5/Documentation/SA_INTERRUPT.txt Sat Sep 18 04:38:53 1999
@@ -0,0 +1,130 @@
+Info regarding SA_INTERRUPT cut from messages by Linus to linux-kernel:
+
+
+Sun, 20 Sep 1998:
+-----------------
+
+A small historical background on the issue..
+
+SA_INTERRUPT _used_ to mean (a _long_ long time ago):
+ - incomplete stack frame, with only the non-preserved registers saved on
+ the frame. This meant, for example, that we couldn't handle signals etc
+ from a fast interrupt handler, because the stack wasn't set up for
+ signal handling.
+ - no PIC masking, and the PIC ACK done after the interrupt handler. This
+ was made possible by guaranteeing that interrupts would not be enabled
+ during SA_INTERRUPT processing, so we didn't need to mask out the
+ interrupt.
+ - no bottom half handling (well, this was originally even before bottom
+ halves existed)
+
+Essentially, the SA_INTERRUPT thing was meant to be a truly lightweight
+interrupt handling system, where it took just a few cycles to get into the
+real handler. It was most useful for serial interrupts that were extremely
+timing-critical (they still are, but CPU speeds have made the overhead
+less of an issue).
+
+These days, SA_INTERRUPT has none of the above meanings. For various
+reasons, not the least of which is just my own sanity, the differences
+between fast and "slow" interrupts have become less and less.
+
+First people wanted bottom half handling as a response to serial
+interrupts, because it made a huge difference to PPP latency. That already
+meant that some of the advantage of a bottom-half interrupt was no longer
+there. Then, with the new SMP code, it just became clear that it made no
+sense at all to have the difference, because the interrupt entry code
+became fairly involved (I definitely didn't want to have two separate
+copies).
+
+These days the _only_ difference that SA_INTERRUPT makes is that a handler
+that has SA_INTERRUPT set will not enable local interrupts on the CPU it
+is running. Or rather, the generic code won't enable the interrupts
+automatically: the low-level drivers can still enable them if they want
+to.
+
+That's a rather arbitrary difference, and not one worth maintaining, I
+think. I should just remove that test.
+
+
+Sat, 11 Jul 1998:
+-----------------
+
+Don't bother with the "fast interrupt". It was never any faster than the
+slow one. It had slightly different semantics wrt the return path, but the
+original meaning of the fast interrupt was that it wouldn't play any games
+with the interrupt controller, because it would never enable interrupts,
+so there were no re-entrancy issues. Not playing any interrupt controller
+games meant avoiding the overhead of several IO instructions, and that
+would have been meaningful.
+
+That was in pre-1.0.x days - even fast interrupts were changed to mask the
+interrupt controller because too many people wanted them. The only
+difference between a fast and a slow interrupt was that the fast one
+didn't do the bottom half handling, and didn't check for signals, and due
+to that a lot of people actually complained about ppp latencies etc.
+
+What you _should_ do, and what the code is actually set up to support
+already, is to instead of having the notion of "fast" vs "slow" (which was
+completely broken), you should look into having the interrupt routines
+return a value. The return path can then check whether it should do bottom
+halves or not depending on that value.
+
+This is because a lot of the things that really want fast interrupts,
+don't actually want the interrupts to be _always_ fast, they want them to
+be fast most of the time. The static "SA_INTERRUPT" flag was too static.
+
+For example, if you have high-speed serial devices, they usually do not
+want to do a bottom half for each interrupt. However, to avoid latency
+problems with packets etc, they _do_ want to be able to say "ok, my
+ping-pong buffer is getting full, please do a bottom half interrupt now",
+or "ok, I got the end-of-packet marker, now it makes sense to get a whole
+packet, so do the bottom half now".
+
+And THEN they want the bottom half handler to be done immediately.
+
+This is actually completely done already, if you look at irq.c. The only
+part that is missing is the return value from the interrupt handlers, so
+right now the code has something like
+
+ if (1) {
+ if (bh_active & bh_mask)
+ do_bottom_half();
+ }
+
+while it instead should look something like
+
+ flags = irq_desc[irq].handler->handle(irq, cpu, ®s);
+
+ if (flags & INTERRUPT_DO_BH) {
+ if (bh_active & bh_mask)
+ do_bottom_half();
+ }
+
+ if (flags & INTERRUPT_DO_SIGNALS) {
+ return through signal checking code
+ }
+
+but it would mean that every interrupt handler would have to return a
+value (it might not be too painful to just make them all return 0, and
+then one by one the ones that know about their needs could be changed).
+
+[...]
+
+> It would be generally useful to handle nested interrupt of different
+> kinds (higher priority irq A interrupts irq B).
+
+We have always done that (since long before 1.0). The nesting is a
+per-interrupt thing, and is only disallowed for the _same_ interrupt.
+
+Also note that if all interrupt handlers on a given IRQ line have the
+SA_INTERRUPT flag set, then 2.1.x (and all earlier kernels for that
+matter) don't allow any nesting at all, because the irq handler won't
+enable interrupt locally. You can still get "nested" interrupts (of a
+different type) on different CPU's, but they'll also have different
+stacks.
+
+[...] nesting a timer interrupt (or something else) with another interrupt
+has always been allowed, and still is. And that is still disallowed by
+"fast" interrupts (it is in fact the only meaning that the SA_INTERRUPT
+flag still has).
+
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/