Messages in this thread | | | Date | Mon, 22 Jul 2002 15:36:57 +0200 (CEST) | From | Ingo Molnar <> | Subject | [patch] remove-irqlock-2.5.27-D7 |
| |
On Mon, 22 Jul 2002, Christoph Hellwig wrote:
> > no, the on is not implicit at all. If you restore into a disabled state > > then it will go from on to off. > > well, for the normal use of it. Okay, I give up, even if the nameing > looks strange in the beginning is is consistant :)
it does precisely what it says:
irq_off() => turn local IRQs off
irq_on() => turn local IRQs on
irq_save(flags) => save the current IRQ state into flags. The state can be on or off. (on some architectures there's even more bits in it.)
irq_save_off(flags) => save the current IRQ state into flags and disable interrupts.
irq_restore(flags) => restore the IRQ state from flags.
while it's true that 'normally' we save irq-enabled state, it's not at all sure, eg. when nested irq_save() is done then the first flags will carry an irqs-on bit, the other nested flags will carry an irqs-off flag - and the nested irq_restore() will restore to irqs-off state.
this is how it has worked in the past 10 years or so.
but i've added this description to the cli-sti guide :-) Check out the -D7 patch:
http://redhat.com/~mingo/remove-irqlock-patches/remove-irqlock-2.5.27-D7
Ingo
- 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/
| |