> Then what's the point of splimp()?  Its entire reason for existing now
   > is to serialize access to malloc() and free().  All you'd do by making
   > them use splhigh() is make it so that nothing else can be squozen in
   > between.  That's silly, and would make it impossible to implement,
   > e.g., a working sound driver, unless one chose to simply bypass the
   > normal hierarchy.

   Then why isn't it called splmalloc(), or something like that?
   splimp() implies to me something to do with networking.

It's historical.  Changing the name would be gratuitous.

Also, I fibbed a little bit in my previous message (though I've
explained all of this before); there is another use of splimp().
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.

Of course, the real solution to all this confusion is to implement
device drivers as kernel threads, and use finer-grain locking.  This
would also help multiprocessor support significantly, and if done
right would even allow us to distribute autoconfiguration over
multiple processors.

   > They're not, except during malloc() or free(), and changing those to
   > use splhigh() wouldn't change that fact.

   Then if the lance driver is running for a long time at splimp(), it's
   probably a bug that we need to fix.

As noted by Jason, on some machines it's not really possible to `fix'
this.  I remember hearing something ages ago about Macs only having 2
interrupt priorities...