From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <f69d68141c2849995ce77133e6eec2a9@vitanuova.com>
From: C H Forsyth <forsyth@vitanuova.com>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] Question regarding interrupt handlers
In-Reply-To: <1049900092.4070.35.camel@utip129>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Date: Thu, 10 Apr 2003 10:24:39 +0100
Topicbox-Message-UUID: 8e01a696-eacb-11e9-9e20-41e7f4b1d025

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.