> Actually, this is problably machine-dependent.  For example, if you have 
 > an HP-IB controller at ipl3 and a SCSI controller at ipl5 on an hp300, 
 > blocking HP-IB "disk" interrupts does not block SCSI "disk" interrupts.  
 > However, some architecures may have interrupt "bitmasks" where each type 
 > of interrupt (network, disk, serial line) corresponds to a "bit" in the 
 > mask ... This is guesswork on my part.  I'm not about to say I 
 > completely understand how interrupts work on the i386, alpha, or pmax.

Interesting.

It's not only architecture- but even machine-model dependant; on pmax
the 3100 can block each interrupt in a bitmask (fpu, video, clock, serial,
ethernet, scsi, and two software interrupts).  Everything is hardcoded
and there are no options.  (A very nice machine for the OS writer :-)
Other DECstation models are much more complex and can't do that, because
many or all types of devices are multiplexed onto a single CPU interrupt
line.

However, here I was mostly talking about possibilities inherent in the
NetBSD machine-independent code; where 'bitmask-like' interrupt masks
are possible the OS doesn't prohibit using them as such.

 > Which boxes won't run SLIP or PPP?  (Actually, do some ports change 
 > splimp() if PPP and SLIP are both not present?  I thought so...)

Sorry for being unclear:  I meant that if you don't have slip or ppp in
your kernel configuration file, you don't need to block serial interrupts
in splimp().  Most of the machines I maintain are ethernet-only and won't
ever run slip or ppp, so I could config that out.  Even more radical
would be changing what splimp() does dynamically when slip/ppp is
actually used.   As Charles said, this may make for hard-to-find bugs
and seems like it's really asking for threads.

  -  Arne H. J.