Messages in this thread | | | Date | Sun, 20 Sep 1998 16:19:46 -0700 (PDT) | From | Linus Torvalds <> | Subject | Re: Today Linus redesigns the networking driver interface (was Re: tulip driver in ...) |
| |
On Sun, 20 Sep 1998, Doug Ledford wrote: > > I think this is the semantic problem. The SA_INTERRUPT flag doesn't say > anything about the speed of your interrupt routine. It flags whether or not > to run the various bottom halves at the end of your interrupt.
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/
| |