Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!linus!genrad!mit-eddie!mit-vax!eagle!mhuxt!mhuxi!mhuxa!houxm!hocda!spanky!burl!we13!ihnp4!ixn5c!inuxc!pur-ee!uiucdcs!ccvaxa!bobvan From: bobvan@ccvaxa.UUCP Newsgroups: net.unix-wizards Subject: Nested spl's really needed? - (nf) Message-ID: <2356@uiucdcs.UUCP> Date: Fri, 1-Jul-83 23:45:32 EDT Article-I.D.: uiucdcs.2356 Posted: Fri Jul 1 23:45:32 1983 Date-Received: Thu, 7-Jul-83 12:13:29 EDT Lines: 26 #N:ccvaxa:15200007:000:1179 ccvaxa!bobvan Jun 30 22:15:00 1983 We're porting 4.1c to non-DEC hardware where it is expensive (time wise) to emulate the DEC spl instruction (you have to wait for the main cpu to go interrupt several I/O processors and wait for them to ack). The new machine is very fast otherwise, including instructions that just plain disable and enable all interrupts (interrupt requests are queued when disabled). We are in the initial design phases of the port, and are considering replacing spl0() calls with an enable interrupt instruction, and all other spl?() calls with a disable interrupt instruction. My question is: Do anyone know of places in the kernel where this will cause us trouble? That is, does the kernel RELY on having discrete nested interrupt levels, or is it just using this handy facility built into DEC hardware? I think we can nest the two software interrupt levels (softclock and network) easily, but it'd sure be nice if we can lump all of the "hardware" spl()'s into one level that is either enabled or disabled. As usual, please reply directly to me, and I'll summarize if interest warrants. Bob Van Valzah ...decvax!pur-ee!uiucdcs!ccvaxa!bobvan Compion Corp. (217) 384-8587