Path: utzoo!attcan!uunet!aplcen!samsung!cs.utexas.edu!texbell!uhnix1!moray!siswat!buck
From: buck@siswat.UUCP (A. Lester Buck)
Newsgroups: comp.unix.wizards
Subject: Re: driver close from exit can't catch signal?
Message-ID: <544@siswat.UUCP>
Date: 30 Jul 90 05:51:06 GMT
References: <26789@nuchat.UUCP>
Organization: Photon Graphics,  Houston
Lines: 39

In article <26789@nuchat.UUCP>, steve@nuchat.UUCP (Steve Nuchia) writes:
> Working on a driver recently I needed to sleep waiting for
> a pending transaction completion interupt in the close routine.
> Since the interupt wasn't guaranteed to come, I wanted to
> be able to catch a signal.  I found that it works when the
> user calls close directly but not when close is called from exit.

Since we all know that, unfortunately, interrupts are never guaranteed to
come, the only thing to do in an industrial strength driver is have a
watchdog timer.  At some reasonable interval (every 1-10 sec, maybe) it
wakes up and checks hardware registers and driver state variables to see if
it should be receiving an interrupt.  It then possibly has to go back to
sleep for one more time period - if no interrupt has been received then, it
does whatever hardware reset is necessary to get things flowing again.

> This is in a SysV thing.  Is this normal and expected?  I couldn't
> find anything about it in the AT+T driver books.

The exit() system calls I have seen atomicly mask all signals at the
beginning, then quite a while later close all files.  There isn't much to be
done with signals anyway, because once exit() is entered, a process never
gets back to user mode, and signal frames (fake calls to signal handlers)
are built on the user's stack, to be executed as he is returning to user
mode.

The standard way to grab signals in a driver is by sleeping with PCATCH
or'ed into the sleep priority.  Then wakeup has sleep return one instead of
zero, and the driver is expected to perform a longjmp(u.u_qsav) when it has
cleaned up whatever (canceling outstanding timers, etc.).  The driver might
even save the u.u_qsav and replace it with it's own jmpbuf to catch a signal
directly (wakeup does the longjmp itself if PCATCH is not set), but that is
probably not recommended.

The PCATCH/u_qsav information is in the AT&T Driver Development Manual,
the excellent manual in a three ring binder.  I paid $100 last year, but
I think it is $200 now.

-- 
A. Lester Buck     buck@siswat.lonestar.org  ...!texbell!moray!siswat!buck