"Richard B. Johnson" wrote:
>
> It just broke. The handler returned before the cause of the interrupt
> was handled. Think LEVEL interrupts. The same interrupt will again
> be entered, looping over and over again, until the tiny bit if CPU
> resource available for the few instants the handler was not in the
> ISR, was enough for the user-mode signal-handler to shut the
> damn thing off, pull the plug, and figure this will never work.
Sorry, I've missed an action writing the previous message (now marked
with a +)
Kernel space:
- irq 9 arrives from our device
- interrupts are disabled
- our kernel space micro handler is invoked
- interrupt source is checked
+ interrupt is acknowledged to our device
- if no notification is pending a signal is notificated for user space
(or a process is marked runnable)
- optionally our device interrupt generation is disabled
- handler returns
- interrupts are enabled
> >
> > User space:
> > - signal arrive (or process is restarted)
> > - action is done
> > - notification is acknowledged (using an ioctl)
> >
>
> Way too late see above.
Don't equivocate me: this not the IRQ acknowledge, it's the acknowledge
of the user space notification.
Also note that this mechanism is not an attempt to demonstrate that to
move interrupt handlers to user space is a good thing. I wanted only to
show a way to permit to have *pseudo* interrupt handlers in user space
also having shared IRQ.
--
Abramo Bagnara mailto:[EMAIL PROTECTED]
Opera Unica Phone: +39.546.656023
Via Emilia Interna, 140
48014 Castel Bolognese (RA) - Italy
ALSA project http://www.alsa-project.org
It sounds good!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
