Path: utzoo!utgpu!water!watmath!clyde!att!rutgers!mailrus!ames!haven!decuac!felix!info-ultrix
From: mouse@Larry.McRCIM.McGill.EDU (der Mouse)
Newsgroups: comp.unix.ultrix
Subject: Re: Device Drivers for MicroVax under Ultrix
Message-ID: <56621@felix.UUCP>
Date: 6 Sep 88 12:44:22 GMT
References: <51452@felix.UUCP> <52120@felix.UUCP> <54075@felix.UUCP>
Sender: info-ultrix@felix.UUCP
Reply-To: mouse@Larry.McRCIM.McGill.EDU (der Mouse)
Lines: 26
Approved: zemon@felix.UUCP
Reply-Path:

Reply-to: mouse@Larry.McRCIM.McGill.EDU (der Mouse)

In article <54075@felix.UUCP>, angelo@jvnca.csc.org (Michael F. Angelo) writes:
[an attribution seems to have been lost here]
>> [spl6() and splx()]
> [speculation on this subject]
> 		splx( x=spl6());
> Will set the prio to spl6 and store the value in x.  It will then
> reset the priority back to what it was previously.

This is dangerous.  Don't do this if there is any chance whatever you
might be called from higher priority than spl6()!  If this sequence is
executed when the processor is at spl7(), for example, IPL will be
*dropped* for a moment to spl6(), thus allowing some interrupts which
should presumably not happen yet (because someone went to the trouble
of setting spl7()).

If you want to determine the current IPL, you can either mfpr(IPL) if
you don't mind being VAX-dependent, or you can splx(x=splhigh()).  (I
believe splhigh() is rather recent; some systems call it spl7().  Be
careful, because systems with splhigh() generally have spl7() as well.)

					der Mouse

			old: mcgill-vision!mouse
			new: mouse@larry.mcrcim.mcgill.edu