On Sun, 2007-02-18 at 22:24 +0100, Arjan van de Ven wrote: > On Fri, 2007-02-16 at 13:41 +0100, Ingo Molnar wrote: > > * Eric W. Biederman <[EMAIL PROTECTED]> wrote: > > > > > So I propose we remove all assumptions from the code that we actually > > > have an array of irqs. That will allow for irq_desc to be dynamically > > > allocated instead of statically allocated saving memory and reducing > > > kernel complexity. > > > > hm. I'd suggest to do this without changing request_irq() - and then we > > could avoid the 'massive, every driver affected' change, right? > > if request_irq() changes we might as well make a variant that takes a > PCI device struct rather than a number, for the 99% of PCI drivers that > use that.. (and then msi and other stuff becomes simpler :)
As a matter of fact, if IRQs has to be handled properly as resources of their respective devices, I think request_irq replacement should take a struct device... In fact, having IRQs hanging off their respective devices would give a proper way to access them via sysfs and implement the affinity etc... thus providing a long term replacement for the current number based APIs. In addition, to facilitate the job of things like IRQ balancing daemons, a /sys/irqs/ could be created containing symlinks to all irqs in the system. Ben. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/