RE: [(repost) git Patch 1/1] avoid IRQ0 ioapic pin collision

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> 
> >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-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/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux