(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
    > reentrance.

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

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.