On Thursday 27 April 2006 21:10, Protasevich, Natalie wrote: > > > > >There are probably better ways to control 224 possible IRQs by their > > >total number instead of their range, and per-cpu IDTs are the better > > >answer to the IRQ shortage altogether. But just going back > > to the way > > >it was wouldn't be right I think. > > >We were able to run 2 generations of > > >systems only because we had this compression, other big systems > > >benefited from it as well. > > > > I don't propose reverting the IRQ re-name patch and breaking > > the big iron without replacing it with something else that works. > > Len, maybe it sounds dramatic and/or extreme, but how about getting rid > of IRQs and just having GSI-vector pair. > I intuitively think that would be possible (not that I have all the > details lined up :) > And this would probably take away confusing IRQ abstraction out once and > for all? I think something like that is done in ia64. x86 users are attached to their interrupt numbers I think back from the bad old days with only 16 interrupts and interrupt sharing didn't work. We might have a revolt in the user base if /proc/interrupts didn't display them anymore @) But I guess using GSI/vector internally only would be fine. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
