On Thu, 8 Jun 2000, Andrew Brown wrote:

> >>Looking through some code, I've noticed that spllowersoftclock() and
> >>spl0() -- IPL-lowering functions -- return 'int'.  splx(), on the
> >>other hand (the other IPL-lowering function), returns void.  in one
> >>place, the return value of spl0() is actually used as the argument to
> >>splx().
> >[...]
> >>I've updated the spl(9) manual page to indicate that the IPL-lowering
> >>functions return 'void.'  I've not changed any ports at this time.
> >>Rather, I expect them to be updated over time.
> >
> >The manual page seems to be uncertain about whether splx() is ever used to
> >raise priority.  I'd assume that it isn't, but it'd be nice for it to be
> >confirmed by Someone Who Knows.
> 
> functional orthogonality aside, wouldn't the return value of splx()
> only be an issue of someone were trying to actually use it elsewhere?

Indeed, but I'd like to know if anything will ever use it, not just if
it's currently used.  More importantly, I'd like to know if splx() can
assume that the spl is being lowered, since this saves a comparison (it
knows it always has to check for soft interrupts).

> it seems to me that splx() ought to be allowed to return void but that
> the others should all return the previous ipl.  i can, after all,
> always ignore the return value of the spl() function if i don't need
> it, right?

Erm, the point is that anyone trying to lower the spl should be doing it
permanently, and hence shouldn't need to know the old one.  Anyone who
needs to know what the spl was is probably doing the wrong thing.

Also, it takes some effort for a function to return int rather than void,
so making the spl-lowering functions return void should make them slightly
faster.

-- 
Ben Harris                                                   <bjh21@netbsd.org>
Portmaster, NetBSD/arm26               <URL:http://www.netbsd.org/Ports/arm26/>