This does not make sense at all for PCI.
In PCI, INTERRUPT ARE NOT SYNCHRONISATION EVENTS! Synchronisation events
are PCI TRANSACTIONS in the context of ordering rules defined by the
specs, but unfortunately only a few hardware implemented that stuff
correctly. People that think interrupts as synchronisations events are not
able to write PCI device drivers that will work reliably in presence of
posted transactions. A PCI interrupt just kicks the driver code that has
then to synchronize correctly with de device, both using PCI transactions
and relying on PCI ordering rules (or the subset available on the involved
hardware).
About a PCI interrupt not handled that makes the system loop under
interrupt, it is a user issue. Using a device without a corresponding
driver is gross idioty, since:
- The OS does not reset the IO BUS at boot.
- So, all devices (intelligent?) that was running before the boot, are
not shut during boot and only a device driver for the device can ensure
the device will not do bad things (once the driver have caught it).
For example, using some programmable device, we can prepare a bomb from
DOS that will explode a few time after if the software does not take
a handle on the device on time.
That's quite feasible using SYM53C8XX chips for example and people that
would boot Linux from DOS without loading a driver for this device, would
see their Linux system explode at their face some time after boot, caused
by the execution of some bad SCRIPTS (kind of program) loaded into the SYM
device prior to the boot of Linux from DOS. :) :) :)
> interrupt handlers for an IRQ return this flag, the kernel belches out
> "Nobody handled interrupt X", which would quickly grab people's attention.
> Unfortunately, it would also grab your attention if there really are
> spurious interrupts that you don't care about.
>
> At the same time, it would be nice to have a RUN_MY_BOTTOM_HALF_PLEASE
> flag. This would be another way to grab driver writer's attention, since
> the bottom halves would break.
Gérard.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/