> > >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. --Natalie > > My point is that the re-name patch has added unnecessary > maintenance complexity to the 99.9% of systems that it runs > on. We pay that price in several ways, including > mis-understandings about what devices are on what irqs, and > mis-understandings about how the code is supposed to work. > > -Len > - 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
