Jeremy Fitzhardinge <[EMAIL PROTECTED]> writes: > Eric W. Biederman 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. >> > > Sounds good to me. In Xen we have 1024 event channels which we need to > map down into a smaller irq. Aside from the complexity of maintaining a > mapping table, that's not a huge issue for now, but when we start > exposing pci devices to guests it all becomes more complex. The ideal > for us is to simply use event channel == irq, which this would allow.
Well you shouldn't need to wait just run with a kernel with NR_IRQS >= 1024. 1024 is stretch but it isn't to bad. There are already x86 boxes that have more pins on their ioapics then that. So x86_64 and with this latest round of patches from Len Brown and I i386 should be able to support that. On the other side 1024 looks extremely limiting for exposing pci devices. If someone gets serious about pushing what is legal with MSI-X you may be in trouble. As a single device is allowed to have 4096 interrupts. Not that I can think of a user for so many but... Eric - 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/
