Re: [9fans] Question regarding interrupt handlers

[C H Forsyth <forsyth@vitanuova.com>]

try this:

have the driver use kproc to create a kernel-only process (ie, kproc)
to do the less critical work;
do only the critical work in the interrupt handler; and have
the interrupt handler wakeup the kproc when there is work for
it to do.  a kproc starts with a priority higher than user level
and if necessary you can use procpriority to adjust it.
if something else is running at a lower priority it will be pre-empted
at the end of the interrupt handler.  (if not, it's a bug and can be fixed.)

you can use this technique as well to deal with interrupt-livelock
(eg, with networked systems under heavy load).  there, the interrupt
handler and kproc also need to manipulate the interrupt-enable
of the device appropriately to ensure progress through a work queue.

the main difference between a kproc and a full process produced by
rfork() is that a kproc lacks a user address space, all kprocs
share a process group and name space, and starts with
no file descriptors.  that's just to say there is
essentially only a single notion of a `process' from the point of view
of most of the system.  there aren't tasks and processes, tasklets,
threads, filaments, looms, broadlooms, etc.