On the m68k mailing list we have a discussion about portability of
interrupts. The main problem is the possible use of sti() in interrupt
handler.
The m68k interrupt architecture uses priorities to achieve nice interrupt
latencies, that means interrupts with higher priorities can preempt
interrupts with lower priority. So far so good, but since it's allowed to
use sti() in interrupts, we have a problem, as the irq source for the
preempted interrupt might still be active and a new interrupt is
generated. What makes this a real problem is, first, that most m68k
machines don't have a central irq controller, that could avoid this, so
it's machine/driver dependend how you acknowledge an interrupt and,
second, on most m68k cpus it's not possible to avoid a stacked interrupt,
so that at the time the first instruction of an interrupt handler is
executed you can have multiple interrupts already on the stack waiting to
be acknowledged in different ways.
So what can we do to allow a safe use of sti() in an interrupt? First we
need to acknowledge the interrupt and then delay the execution of the
interrupt until we last one on the interrupt stack. But this creates a
problem, when we want to use standard drivers, as the interrupt handler
had to be splitted and the delaying of the interrupt creates additional
overhead.
This finally raises the question if a sti() is really necessary in an
interrupt? What's wrong with save_flags()/restore_flags() or if someone
thinks, he wants to allow interrupts now (what assumes ia32 style
interrupts btw), why not using a different macro for this? This would make
the life far easier and wouldn't destroy the last bit of interrupt
perfomance, that we still have.
bye, Roman
-
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/