Looking at irq handling in the kernel from a generic perspective I
see two problems.
- There are a huge number of possible interrupt sources but in
practice very few of them are used. So we need a large
irq_desc[NR_IRQS] array that mostly goes unused. If we try for
tighter pacing we get into all kinds of weird issues with irq
remaping and confusing human beings and sometimes the code.
Even with a large enough NR_IRQS we still get weird issues of
allocating and freeing elements in the array which is just needless
complexity.
- When dealing with interrupts we have no universal value that means
we don't have an irq. Inside the arch code we have to do
something different then in drivers because 0 is valid interrupt and
even at the level of drivers there are cases where the type is made
int irq and negative numbers are used.
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.
To do this I believe will require a s/unsigned int irq/struct irq_desc *irq/
throughout the entire kernel. Getting the arch specific code and the
generic kernel infrastructure fixed and ready for that change looks
like a pain but pretty doable.
Getting the drivers changed actually looks to be pretty straight
forward it will just be a very large mechanical change. We change the
type where of variables where appropriate and every once in a while
introduce an irq_nr(irq) to get the actual irq number for the places
that care (ISA or print statements).
Beyond that I did a quick test compile with just the interrupt.h and
pci.h changed and big chunks of the drivers compiled without errors.
Other drivers had more issues that mostly looked like they had an
internal irq number variable that needed updating.
I think we can make this change fairly smoothly if before the code is
merged into Linus's tree we have a patchset prepared with a all of the
core infrastructure changes and a best effort at all of the driver
changes. Then early some merge window we merge the patchset, and
fixup the drivers that were missed.
Andrew, Linus if you think this is a horrible idea I clearly cannot
pull this off, but if not I will start working up patches for 2.6.22
or more likely 2.6.23.
I expect the most it makes sense to aim for 2.6.22 are the genirq
changes so the internal arch code is passing struct irq_desc
everywhere internally.
Hopefully with this I can get the irq code in a shape where you don't
have to have been staring at the code for years to make sense of.
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/
[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]
