[patch] remove-irqlock-2.5.27-D7

[Ingo Molnar]

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