Alan Cox wrote:
>
> > (i.e. counted). An alternative to queuing (user selectable) is to block
> > interrupt generation at hardware level in kernel space immediately
> > before notification.
> >
> > I'm missing something?
>
> IRQ 9 shared between user space app and disk. IRQ arrives is disabled and
> reported, app wakes up, app wants to page in code, IRQ is disabled, box dies
>
> You have to handle that in kernel space, at least enough to handle the
> irq event, ack it and queue the data
I try to be more clear:
Kernel space:
- irq 9 arrives from our device
- interrupts are disabled
- our kernel space micro handler is invoked
- interrupt source is checked
- 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)
Kernel space:
- if we have other notifications to do, do one
- optionally our device interrupt generation is reenabled
--
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/