> >Are the conventions for when to use which splfoo() documented in section 9 y=
> >et?

This would be really neat.

> For example, using splimp() to lock kernel memory allocation, makes
> halfway-accurate profiling of kernel networking code infeasible.

Now that you mention it, what exactly is it that splimp() in NetBSD
should be used for?

It used to be that an IMP was the BBN box you plugged into when you were
attached to the ARPAnet (was it an `Interface Message Processor'?), so
splimp() was essentially the interrupt level of the network device
drivers.  This appears to be the thing that is now supposed to be
splnet() in NetBSD (which used to be the thing which is now splsoftnet()
in NetBSD), except that a lot of stuff in /sys/net* still seems to use
splimp() to block the network device drivers, though other stuff seems to
explicitly think it should be used to block network+tty device drivers.

I had thought until a couple of minutes ago that splimp() had been
left to be exclusively used by the kernel memory allocator (which
I think acquired the splimp() because it allocates mbuf's and the
original mbuf allocator, which was used only by the network code,
ran at splimp() to block the network device drivers which were using
it), based in part on comments in arch/i386/include/intr.h, even though
I'm pretty sure very old BSD kernels didn't expect splimp() to protect
all memory allocation, or even terminal driver interrupts for that matter
(SunOS 3.x certainly had some of the tty hardware running above splimp(),
as did some of the vax kernels we had.  This made slip harder).

So if you have splnet() for network device drivers, and need something
other than splimp() for memory allocation, what is it that is left for
splimp() to do?

Dennis Ferguson