Ethin wrote:
And I suspect that the only reason Intel hasn't made the IDT support 2^32 interrupts is because it would break existing OSes. Even if doing so would be a very, very good idea, IMO, and would support the (probably impossible) case of 16777216 devices in PCIe, and would support practically every kind of computer setup for centuries to come, if not longer.
You know, I'd like the exact opposite of that: Could we please take a page from PowerPC and get a way to receive all external interrupts at a single place, then maybe push an identifier to the stack? Because right now, I already have two-hundred twenty-four interrupt handler routines that are all doing basically that in software. This also can't be a big problem in the CPU as it already knows which interrupt is being invoked, and it already has a way to push things on stack. (It also can't be a big problem to make the new feature switchable with a bit in, say, EFER. Or make a new MSR if you must.)
Or to make it short, I want the interrupt number as data, not as a code address.
For those curious, on PowerPC, all exceptional conditions end up at a certain address defined in the architecture, and "external interrupt" is one such condition. All external interrupts go to address 0x700 (physical). To find out which device interrupted you, you have to ask the PIC, thus making the interrupt number available as data. The architecture only supports this one interrupt level, and a given machine could have any PIC implementation desired, supporting however many interrupts you want.
Now that's a beautiful idea. I imagine it would minimize code by quite a bit. My Rust kernel has all interrupts -- all 256 of them -- defined because I wasn't sure how to dynamically tweak the IDT back when I did that, and if x86 did this I could just do a single handler that dispatches to other functions depending on what the interrupt really is.