That's fairly expensive. Usually it's really cheap to block the irq's (you
can do so essentially in software), but then unblocking the interrupt and
re-send pending ones can be really rather nasty.
We can do it even on a "per-request_irq()" basis (as opposed to a
"per-irq-line" basis), but it gets hairier and hairier (it would really
have to be a "per-cpu-and-request_irq()" thing, and suddenly it isn't very
cheap at all).
There's a _lot_ to be said for just being fast and simple. A normal irq
spinlock is exactly that. Yes, it blocks everything on that CPU, but
that's where minimizing the critical region comes in.
And I'm not claiming that minimizing the critical region is simple. But it
can often be done with a good design (the current bottom half code is
certainly a good design in that respect).
> > Linux very obviously already supports the "disable_irq(irq)" notion,
> > and it should work correctly these days now that we understand better
>
> What happens on a pending IRQ that is disabled. Are the semantics of
> disable_irq() reliably one of 'leave pending' or 'drop' ?
They are certainly meant to be the reliable "leave pending" kind (but for
obvious reasons just a single pending event, kind of like traditional unix
signals).
That can be hard on certain hardware, but it is the nicest behaviour.
However, it _is_ fairly expensive (again, the disable itself is not the
problem, the enable is). Certainly an order or two more expensive than
just a simple spin-lock.
Linus
-
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/