[patch] remove-irqlock-2.5.27-D7

Ingo Molnar
2002-07-22T13:34:56Z

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