[parisc-linux-cvs] linux-2.6 willy

[Grant Grundler]

On Sat, Jan 01, 2005 at 04:02:33PM +0000, Matthew Wilcox wrote:
> Right, you disable an interrupt, not an interrupt handler.

IMHO - this is wrong by design. It means one driver can mess
with the behavior of another driver. e.g. shutting down one NIC
could disable the interrupt for another NIC.

> The generic
> IRQ code supports nested disable/enable calls, precisely because of this.

nesting disable/enable device IRQ makes no sense to me. 
The code path should know if a particular IRQ is disabled (or not)
or if it needs to be disabled.  I differentiate device IRQ code path
from disabling the CPU interrupts (e.g. spinlock_irqsave())
because the device IRQ's are typically much more expensive
to enable/disable.

> Our code does the wrong thing, which is one of the reasons I'm looking
> to get rid of it.

ok. Just keep in mind the trade-offs.

> > Ditto for mask/unmask calls
> > that have been recently removed.
> 
> I determined they weren't necessary -- in my latest development tree,

I agree - basically no drivers used mask/unmask. And we don't need it under
parisc since we don't support nested interrupts anyway.

> I deleted the enable/disable_irq calls that I replaced them with in the
> current tree.  Haven't booted that change yet, but it's worth noting that
> dino has *never* masked/unmasked irqs; only wax/lasi/asp do.

And the others probably don't need to either.
But I'm not as familiar with them.

> Eventually, I hope to be able to create kernel/irq/iosapic.c and
> share it between ia64, parisc and i386, but that's a fair way off yet.

I originally had that as a goal but I'm not sure anymore it's worth it.
Sharing code is good for some things but not everything.

thanks,
grant