Yes. Note the "prior to 1.2". People have had patches like this floating
around for quite some time, but the timing has been bad. I think I
actually got a similar patch just before 2.0 too - and I'm definitely not
likely to change basic irq behaviour before making a stable release..
> As to the structure of it. I'd rather mark_bh() set the flag so the fast
> interrupt return wasnt taken. Or maybe mark_bh_nodefer()
mark_bh() already sets the flag that indicates we want to do the bh, it
makes no sense to have that set any other flag. If we wanted that we might
as well just always test bh_mask and bh_active.
What we want to have is to allow the interrupt handler to set the bottom
half bit, but _also_ say that "yes, I set the bit, but there is no
overwhelming reason to act on it immediately on return as I'm likely to
gather more data".
So if anything, we want to have "mark_bh_defer()", not nodefer. But the
act of delaying is really conceptually totally separate from the act of
marking the bottom half. Which is why I don't want to mix them.
Having the interrupt routine return a status word is really good, because
that can be used for other things too. If you look at the current irq.c
code for interrupt dispatch, you can see that we already _have_ the status
word, but the problem is that it is fixed (action->flags).
So instead of having this fixed status word, we'd have the irq handler
return the status it wants at run-time (the status word currently contains
information about whether it is a fast or slow interrupt, but also whether
we should use this interrupt for the randomizing stuff). Potentially we
can then add other dynamic flags.
Linus