The same thought has crossed my mind as well for ARM; the hardware
interrupt controllers are becoming more inteligent, and there is
the possibility that system designers will mix inteligent interrupt
controllers with standard types.
Also on ARM, we're currently defining NR_IRQS on a per-platform class
and even a per-platform basis.
I've been wondering whether we even need to think about passing some
alternative identifier of an IRQ line around, instead of a number.
> Im working on top of Andrey Panin's irq consolidation patches
> in the hope that it goes in first and other architectures can benefit
> from these changes (I think SGI's ia64 boxes have similar issues as
> well as large x86)
I believe Andrey's IRQ consolidation provides a single flat IRQ
structure. Unfortunately, this doesn't reflect the reality that we
have on many ARM platforms - it remains the case that we need to
decode IRQs on a multi-level basis.
Given the rate which ARM has progressed and evolved during the existing
2.4 lifespan, it doesn't make much difference to us whether these
changes happen now or later. If it happens later, it will be during
the 2.6 series of kernels, so "now" is preferable. Reality is such
that ARM hardware moves a hell of a lot faster than x86 hardware.
-- Russell King (rmk@arm.linux.org.uk) The developer of ARM Linux http://www.arm.linux.org.uk/personal/aboutme.html- 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/