Note that the counter I was talking about was the "counter of delayed
interrupts", ie the counter that tells us how many interrupts happened
during processing of another interrupt or during "disable_irq()". I think
that counter should not be a counter at all, but a single bit of
information, because that is how the hardware does it for all other cases
where we disable interrupts.
> disable_irq(x);
> ... some stuff ...
> disable_irq(x);
> ...
> enable_irq(x);
> ... some stuff ...
> enable_irq(x);
The nesting of disable/enable_irq() is a totally different issue, although
there too I think that the counter is (a) not very useful and (b) not how
it has ever beed done before.
However, for this case I don't actually care all that much, because nobody
should be using nesting anyway, and as such I prefer it to not be a
counter.
> does? On the Sparc we treat it the way you think it should work
> (enable_irq() turns it on and no depth checking is done) however our
> case is different since we've written and maintain all our drivers and
> like to not think of ourselves as clueless driver developers ;-)
Just wait for when the Sparc enters the real world instead of the little
sheltered play-pen of Sun.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu