Path: utzoo!attcan!uunet!tut.cis.ohio-state.edu!ucsd!ames!dftsrv!mimsy!chris
From: chris@mimsy.umd.edu (Chris Torek)
Newsgroups: comp.unix.wizards
Subject: Re: driver close from exit can't catch signal?
Message-ID: <25838@mimsy.umd.edu>
Date: 2 Aug 90 07:21:19 GMT
References: <26789@nuchat.UUCP> <544@siswat.UUCP>
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
Lines: 37

In article <544@siswat.UUCP> buck@siswat.UUCP (A. Lester Buck) writes:
>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.

(I left this in because it bears repeating.  `Expect hardware to malfunction.')

>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.).

Note that things are quite different in Berkeley Unix.

In 4.[123]BSD and derivatives sleep() either returns normally (after a
wakeup()) or does not return at all (via longjmp).  In 4.3-Reno, and
thus eventually in 4.4BSD, sleep does take a PCATCH flag, but:

	a. the routine is called tsleep(); it has four parameters, and
	b. one of these is a timeout (in clock ticks);
	c. tsleep returns an error number from "errno.h", which is
	   either 0, EWOULDBLOCK, ERESTART, or EINTR.

ERESTART is a `special' internal error code that causes a system
call to be restarted (on the VAX and Tahoe, by backing up the PC
so that the call is redone).  tsleep returns EWOULDBLOCK if the
timeout expires before a wakeup() occurs.  It returns ERESTART or
EINTR only if the PCATCH flag is set and a signal occurs; in this
case, which is chosen depends on whether the SA_RESTART bit is set
in the signal action (this is a POSIX thingie).

In particular, setjmp and longjmp are both gone in 4.3BSD-Reno.
(setexit and reset are still there, if you compile in the kernel
debugger.)
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris@cs.umd.edu	Path:	uunet!mimsy!chris