Development Plan Proposal for Unifying Interrupt and PCI APIs
Thomas.Doerfler at imd-systems.de
Sat Oct 23 19:34:44 UTC 2004
> Take the case where a device is generating interrupts very quickly, and a
> device sharing that interrupt line generating interrupts more slowly.
> If the first device handler services the interrupt, then returns with the code
> which says an interrupt was serviced, and so the next handler is not polled.
> If the second device is actually generating an interrupt, the interrupt
> handler will be called again. If in the intervening span of time, the first
> device also signals an interrupt again, the first device will again be
> serviced, and the second device will not.
> That may be desired behavior, but it needs to be documented very clearly.
Surely you are right.
But let's connect the same devices to different interrupt levels
(say on a m68k architecture), your "first" device connected to a
higher interrupt level (let's say 5) and the second one to a
lower level (let's say 4).
Both devices fire an interrupt at the same time. Due to higher
priority, the first device will be serviced first. When it fires
again at the end of its service routine, it will be serviced
once again, even before the second one gets serviced for its
first request. That's why this is called a priorized scheme. The
chained shared interrupt scheme I described has quite similar
Would it make sense to have a selection option between "priority
scheme" (when the first handler of a given interrupt line has
been found whose device has fired an interrupt) further handler
polling will be ommitted, or a "equal priority" scheme (anybody
has a better name for that?) where the polling will always be
executed for all handlers attached to a certain interrupt line?
> Chris Caudle
IMD Ingenieurbuero fuer Microcomputertechnik
Thomas Doerfler Herbststrasse 8
D-82178 Puchheim Germany
email: Thomas.Doerfler at imd-systems.de
PGP public key available at: http://www.imd-
More information about the users