> On Thu, Sep 02, 1999 at 09:41:48PM +0200, Gerard Roudier wrote:
> > >
> > > I'd vote for changing the return value of the interrupt handlers to
> > > (int), and return a I_DID_SOME_STUFF flag. That way, if none of the
> >
> > 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).
>
>
> I appear to be missing something. What do PCI synchonization issues
> have anything to do with a driver giving the OS hints? The delivery
> of interrupts to the handlers would not change, but only that messages
> *might* get printk'd if an interrupt occurs and no handler thinks that
> the interrupt belongs to it. How often do spurious interrupts occur
BTW, "share" is kind of opposite of "belong".
> in a correctly functioning computer that shares interrupts between,
> say, a NIC and SCSI card?
An PCI interrupt that occurs and no device (sharing the INT line) having
things to do may happen in PCI without being a spurious interrupt (even if
this is probably a rare situation). Your statement let me think that your
knowledge on PCI is just ISA+.
> One thing that you could do with the I_DID_SOME_STUFF flag is use the
> statistics to reorder the execution of interrupt handlers so that the
> device that causes the most interrupts gets called first. Might be
> cool, difficult to tell.
You _must_ call all interrupt handlers that requested the same IRQ when
this IRQ is raised. So your flag does not optimize anything.
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/