Re: interrupt handling w/o handler?

Jeff Garzik (jgarzik@pobox.com)
Sun, 11 Jul 1999 13:42:21 -0400


Mark Lord wrote:
>
> Jes Sorensen wrote:
> >
> > >>>>> "Jeff" == Jeff Garzik <jgarzik@pobox.com> writes:
> >
> > Jeff> Is there a function available to drivers that allows something
> > Jeff> like: ... interruptible_sleep_on_irq (9); /* wait on IRQ 9 */
> ..
> > You have to register a handler for thaat, otherwise how are you
> > guaranteed that the interrupt is handled and the hardware doesn't keep
> > reasserting the same interrupt over and over again.
>
> I think Jeff might be looking for a function such as:
>
> interruptable_sleep_on_irq(n):
> -- allocate unused irq(n), bind in generic_irqhandler(n)
> -- save PID in wakeuptable(n)
> -- unmask irq(n)
> -- sleep until woken up by generic_irqhandler(n)
> -- deallocate irq(n)
> -- exit
>
> generic_irqhandler(n):
> -- permanently mask irq(n)
> -- wakeup(wakeuptable(n))
> -- exit
>
> Those two functions could then be made available to user-level
> either through /proc or a newsyscall, thereby permitting *user-level*
> interrupt handling ("virtual device drivers" from userland).

Exactly!

It seems to me that many drivers do not need a specific interrupt
handler, they simply use interrupts to wait until an event occurs. I
think a simple, generic interrupt handler that simply lets you know that
an event occurred would be very useful.

Specifically in video drivers, one can do

do {
status = read_fifo_register() & mask;
} while (!status); /* poll for fifo */

or....

interruptible_sleep_on_irq (video_irq);
/* FIFO is ready, proceed... */

Now I _could_ write an interrupt handler to do this sort of thing, but a
generic method seems much more useful, and keeps the code much, much
cleaner. There might be a generic "register_generic_irq_handler()" step
at video driver init, if needed.

I hadn't thought about IRQ handling from userland, that _is_ an added
bonus.

Regards,

Jeff

-- 
One of the most overlooked advantages to computers is...  If they do
foul up, there's no law against whacking them around a little.
                -- Joe Martin

- 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/