Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!cwjcc!hal!nic.MR.NET!tank!mimsy!chris
From: chris@mimsy.UUCP (Chris Torek)
Newsgroups: comp.unix.wizards
Subject: Re: Surprising fact about STREAMS service modules
Message-ID: <15167@mimsy.UUCP>
Date: 26 Dec 88 06:03:01 GMT
References: <4385@hcr.UUCP> <313@taniwha.UUCP> <11047@ulysses.homer.nj.att.com>
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
Lines: 30

In article <11047@ulysses.homer.nj.att.com> smb@ulysses.homer.nj.att.com
(Steven M. Bellovin) writes:
>A persistent bug source, in many versions on the UNIX system, is that
>splN() calls, other than splx(), unconditionally set the interrupt
>level to the indicated value, rather than *raising* it to that value.
>It is almost never correct to lower an interrupt level, except via
>splx() or spl0().  Sun has gotten some of those right; the symbolic
>spl() calls (splimp(), etc.) check the current level before raising it.
>4.3bsd is wrong; I haven't been able to check 4.3 Tahoe yet.

Alas, some VAX hardware (and some other hardware) requires this sort of
foolery.  The Qbus interrupt system is such that a device that is
supposed to operate at IPL15 (such as a DHV11) may in fact interrupt at
IPL17, if there is a device behind it on the bus that requests at BR7.
It is therefore good for performance to explicitly lower the interrupt
priority in the service routines for Qbus devices.  the UDA50 driver,
for instance, works on the RQDX controllers as well, so udaintr()
begins with

	#ifdef QBA	/* was #ifdef VAX630 */
		(void) spl5();
	#endif

A more flexible approach might be to define `raisepl' inlines (perhaps
`rpl'?), to be used in appropriate places.  Or simply use the current
system and declare that all kernel hackers must keep their priorities
straight :-) .
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris@mimsy.umd.edu	Path:	uunet!mimsy!chris