Subject: spl naming etc
To: None <tech-kern@NetBSD.ORG>
From: Arne H. Juul <email@example.com>
Date: 01/03/1996 01:39:03
(This discussion comes from port-pmax. I hope it's ok for me
to move it here instead, since it's no longer pmax-specific).
Let me summarize a bit:
splimp() currently has two uses (quoted from Charles):
a) > Serialize access to malloc() and free().
b) > Because of SLIP and PPP, network drivers (and thus manipulation of
> protocol queues) can run at both spltty() and splnet(). Therefore,
> manipulation of protocol queues is done at splimp() to prevent
This is probably historical: The spl used to be 'levels' in a priority
hierarchy, where splimp() was at a suitable point in the hierarchy to
use it for malloc()/free(). [Those with more 'history' please correct
if this is wrong.]
But in NetBSD the current spl() structure is not strictly hierarchic;
splnet() can block just network interrupts, splbio() just disk interrupts,
spltty() just serial interrupts and so on. [This is a simplified picture
of course, ignoring parallel ports etc...] At least this is my current
understanding of the NetBSD source code. Of course many machines must
have the spl() routines in a hierarchy anyway, because of the hardware
So maybe we *really* should have split splimp() into splprotoqueue()
and splmalloc(), if we wanted to be "pure" (arpanet is dead, after all).
However, this is probably not a good idea since it would break a lot of
device-driver / kernel source code compabitibility.
So, what we need to do is ask:
- does lots of people / drivers / other bsd operating systems assume
splimp() can/should be used to block malloc, and use it for that purpose?
[I don't know the answer to this.]
If not, we *can* split splimp() into slightly modified splimp() blocking
net/tty, and splmalloc() blocking 'all-drivers-using-malloc()' (whatever
that may mean). Of course, on many machines these two might have the
same implementation, but if there are some machines where it makes for
a huge win, it should be considered. I don't know whether it would be
a huge win, a small win, or no win at all.
I'm pretty sure renaming splimp() in the network code would be a very
very bad idea. (No, "splprotoqueue" is *not* seriously meant.)
However, if the current dual-purpose splimp() is kept, it needs to
be documented as such, since it seems most people [including me, after
having read a bit in the Stevens/Wright book] assumed it did just b) above.
I'll volunteer to write the man page.
Now what about another (maybe stupid) idea: Most boxes doesn't
necessarily run slip or ppp at all. What about making splimp() not
block tty interrupts if slip/ppp is not configured? This *might*
be a huge win on many machines for serial port reliability, which
would be nice for driving printers / terminals. [Of course, you need
serial port reliability when using slip/ppp too!]
- Arne H. J.