Michael K. Edwards wrote:
Still open, though it's a pity you're more interested in my flawed understanding that in the possibility that the kernel could be systematically made more robust against hardware bugs and coding errors by the simple expedient of putting all the ISRs in before turning on any IRQ that might be shared. Or are you telling me that's already been done? (Yes, I am aware that this interacts entertainingly with hot-plug PCI. Yes, I am aware that there is a limit to how much software can fix stupid hardware. But surely there is room for an emergency IRQ suppressor to let chip initialization code kick in and force the hardware to a known state.)
How do you propose to do this? Drivers can get loaded and unloaded at any time. If you have a device generating spurious interrupts on a shared IRQ line, there's no way you can use any device on that line until that interrupt is shut off. Requiring all drivers to be loaded before any of them can use interrupts is simply not practical. If a system has a device that generates interrupts before they're enabled, and the firmware doesn't fix it, then some platform-specific quirk has to handle it and shut off the interrupt before it allows any interrupts to be enabled. (We have such a quirk for certain network controllers where the boot ROM can leave the chip generating interrupts on bootup.) -- Robert Hancock Saskatoon, SK, Canada To email, remove "nospam" from [EMAIL PROTECTED] Home Page: http://www.roberthancock.com/ - 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/
