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/
This archive was generated by hypermail 2b29 : Tue Jul 23 2002 - 22:00:38 EST