Hmmm...
IRQ's are either hardware or software generated signals intended to get the attention of the CPU, as the hardware that generated it needs to be serviced.
In the PC world, IRQ's are mostly hardware generated. and the number for the IRQ is the priority at which the IRQ is to be serviced, with the lower number having the higher priority.
IRQ sharing is a means to allow the deficient design of the PC to support more devices. Until recently (i.e. newer extended IRQ support), there were a very limited number of available hardware IRQ's.
Until the PCI architecture came along, you could not share interrupts as multiple generations of the same IRQ would only show up as one interrupt to the CPU.
The PCI architecture also had some short comings in the design as only 3 hardware interrupts were ever specified to be available. Again, this was due to the original design of the PC.
Interrupt sharing has always been a problem, as the design requires the manufacturer of the hardware device to validate whether or not the interrupt is intended for the hardware via an interrupt handler function.
Basically, the interrupt handler looks at its hardware to see if an interrupt was generated (most cards have status registers to read this information from). If it does, then it services the interrupt, and then the next device interrupt handler sharing the interrupt is called and so on.
This adds overhead for every device which shares an interrupt. It also puts the user at risk, as you are assuming the driver manufacturer has properly written its software driver to share interrupts.
Performance can suffer dramatically depending on which devices are sharing which interrupts. Reliability is often compromised as well.
New generations of chips and motherboards are now available which allow up to 64 hardware interrupts. Windows 2K and XP will use these, if the following conditions are met:
1) APIC must be available (Advanced Programmable Interrupt Controller)
2) ACPI must be disabled
When you use ACPI, Windows 2K and XP will use software based interrupts, where a table is built for all the devices and all hardware interrupts are funneled through an OS supplied function which attempts to call the correct Interrupt handler for the device that actually generated the interrupt.
One of the things lost in this scheme is the interrupt priority. Two devices at different hardware interrupts are serviced based on the order they were installed, rather than the actual interrupt priority.
That help?
