Subject: Re: spl naming etc
To: None <email@example.com>
From: Arne H. Juul <firstname.lastname@example.org>
Date: 01/03/1996 08:40:44
> 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.
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
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.