At some point in the past, I wrote:
quoted text
>> I'm certainly in favor of the move; IRQ stacks could be made
>> rather deep and cheaply at that. I may get around to writing it this
>> week if no one else does it first.

On Tue, Mar 06, 2007 at 08:28:35PM -0800, Arjan van de Ven wrote:
quoted text
> the irq stacks aren't the problem; RH at some point accidentally shipped
> a kernel with 4k *shared* irq/user context stack and even that gave
> almost no issues.
> irq's really shouldn't actually nest; it's bad for just about everything
> to do that (but that's another story, I would *love* to get rid of the
> "enable irqs" thing in the x86 irq path, it hurts just about anything in
> reality)

What do you see as the obstacle to eliminating nested IRQ's? It doesn't
seem so far out to test for being on the interrupt stack and defer the
call to do_IRQ() until after the currently-running instance of do_IRQ()
has returned, or to move to per-irq stacks modulo special arrangements
for the per-cpu IRQ's. Or did you have other methods in mind?


-- wli
-
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/