>>> That aside, can softints even interrupt softints, or are the >>> priorities only about who goes first if two softints are scheduled >>> `simultaneously' (as far as softint_dispatch can discern)? >> The latter, iiuc. > I checked on arm, and it looks like higher-priority softints can > interrupt lower-priority softints, [...]
They certainly used to be able to. When I first saw soft interrupts (back around BSD4.3, I think), they looked a whole lot like the VAX SIRR/SISR facilities, which _are_ a "higher priority softints can interrupt lower priority ones" system. (This would not be surprising, given how influential the VAX was at the time.) There were even, IIRC, comments about how _this_ softint was higher priority than _that_ softint because its subsystem should have better response time. I've seen some softint implementations which map all the softint levels to something like one or two hardware priority levels. I've always seen this as a case of "the hardware doesn't make it easy to do this right and doing it right in software is more work than I want to get into now". Not that am any kind of authority on NetBSD's softint design. But then, I'm not convinced anyone truly designed it, rather than it just growing by accretion since softints were created (by UCB?). /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML [email protected] / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
