Note that this is no longer true.
I 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.
Linus
-
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/