* Alan Mayer <ajm@sgi.com> wrote:

quoted text
> > but it doesnt really depart from the current status quo of huge 
> > [NR_IRQS] arrays either. Patches that make NR_IRQS a variable are 
> > welcome :)
> 
> Good luck with that.  If i come up with something that's elegant 
> enough to make it worth the risk, I'll let you know.  Changing NR_IRQS 
> to a variable touches every arch and a lot of drivers.  Someone is 
> bound to choke on it, so it has to be something worth fighting for.

well, i dont it has to be (or it should be) an all or nothing patch, 
given the complexity and risks involved.

- we should first introduce a nr_irqs variable and a Kconfig switch 
  (say CONFIG_ARCH_HAS_DYNAMIC_NR_IRQS) for architectures to toggle. If 
  the switch is toggled, nr_irqs is a variable, otherwise it's a carbon 
  copy of NR_IRQS. Some array-definition, declaration and initialization 
  wrappers are provided as well.

- then the core code, x86 and most drivers can be converted to nr_irqs.
  The switch might initially even be user-selectable if
  CONFIG_DEBUG_KERNEL, to ease regression testing.

- other architectures will follow one by one, fixing their
  arch-dependent drivers as well in the process

- finally we get rid of the wrappers.

	Ingo
--
unsubscribe notice
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/