>> Suppose, for the sake of argument, one is writing a NetBSD driver
>> for hardware where it's not always possible to tell whether the
>> device generated an interrupt on a shared IRQ, or not.
> That device is fundamentally broken.  There MUST be interrupt status
> bits that the device presents to allow you to know.  There is no way
> to reliably share interrupts otherwise.

While I do not disagree with the first sentence, I disagree with the
last.  It would be equally possible to reliably share interrupts if
either (a) at most one such device is on any given interrupt line (just
check it last) or (b) the interrupt-acknowledge dance for that device
were (i) race-free with respect to interrupt generation and (ii)
harmless if no interrupt were pending.  Oh, and (iii) fast enough to
not be a performance pig in the presence of high interrupt rates from
other devices sharing the line.

I know of no examples of (b), but I see no reason why one couldn't
exist.  As a reasonably plausible example, consider a network card with
onboard buffering for incoming packets; when its buffer space gets low
(and presumably on other conditions), it interrupts and you pick up
packets.  But if you get an interrupt and you find packets pending, you
don't know whether it has interrupted for them or not - it may depend
on things such as possible other uses of its onboard memory.  (Maybe
it's got multiple ports on the back with a small switch built in, and
the switch buffers are shared with the buffers used for host packets.)

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B