[9fans] Question regarding interrupt handlers

[9fans] Question regarding interrupt handlers

[Martijn Punt]

Hi,
I'm relatively new to Plan 9 (and this mailinglist) and am currently
developing a device driver for a satellite tv-card for plan 9. My
previous experience is limited to Linux, and have a question about
interrupt handlers:

How do interrupt handlers in Plan 9 cope with large amounts of work
having to be done in order to handle an interrupt?
Is there a way to split the task in two parts, one to be handled
immediately and the other to be executed at a more convenient time?

Are there standard approaches for this problem in Plan 9, similar to the
approach of tasklets and bottom half processing in Linux?

Any help will be greatly appreciated,
Greets Martijn Punt

Re: [9fans] Question regarding interrupt handlers

[Fco.J.Ballesteros]

[-- Attachment #1: Type: text/plain, Size: 123 bytes --]

if you have to do something in `background' out of the interrupt handler
you can just create a kernel thread for the task.

[-- Attachment #2: Type: message/rfc822, Size: 2090 bytes --]

From: Martijn Punt <m.punt@student.utwente.nl>
To: 9fans@cse.psu.edu
Subject: [9fans] Question regarding interrupt handlers
Date: 09 Apr 2003 16:54:52 +0200
Message-ID: <1049900092.4070.35.camel@utip129>

Hi,
I'm relatively new to Plan 9 (and this mailinglist) and am currently
developing a device driver for a satellite tv-card for plan 9. My
previous experience is limited to Linux, and have a question about
interrupt handlers:

How do interrupt handlers in Plan 9 cope with large amounts of work
having to be done in order to handle an interrupt?
Is there a way to split the task in two parts, one to be handled
immediately and the other to be executed at a more convenient time?

Are there standard approaches for this problem in Plan 9, similar to the
approach of tasklets and bottom half processing in Linux?

Any help will be greatly appreciated,
Greets Martijn Punt

Re: [9fans] Question regarding interrupt handlers

[Sape Mullender]

> How do interrupt handlers in Plan 9 cope with large amounts of work
> having to be done in order to handle an interrupt?
> Is there a way to split the task in two parts, one to be handled
> immediately and the other to be executed at a more convenient time?
>
> Are there standard approaches for this problem in Plan 9, similar to the
> approach of tasklets and bottom half processing in Linux?

You can create a kernel process (look at the implementation of --
and calls to -- kproc in the kernel) that deals with the bulk of the work
of the handler.  Alternatively, you can let a user process dod the bulk
of the work in the device driver.  The interrupt could be used to set
the driver in motion.  The driver would do a sleep() and the interrupt
routine a wakeup().  You can use ilock() for mutual exclusion between
driver and interrupt routine (but you're not supposed to hold an ilock
for more than a handful of instructions).

	Sape

Re: [9fans] Question regarding interrupt handlers

[C H Forsyth]

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.