From owner-freebsd-arch Fri Mar 16 2:24:58 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 1C0E437B718; Fri, 16 Mar 2001 02:24:54 -0800 (PST) (envelope-from bde@zeta.org.au) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id VAA09872; Fri, 16 Mar 2001 21:24:51 +1100 Date: Fri, 16 Mar 2001 21:24:34 +1100 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: John Baldwin Cc: arch@FreeBSD.ORG Subject: Re: Proposal for the CPU interrupt API In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 15 Mar 2001, John Baldwin wrote: > ... > Typically, interrupts are disabled in the following fashion: > > u_int foo = save_intr(); > disable_intr(); > ... > restore_intr(foo); > > Unfortunately, this can be somewhat expensive on the Alpha, as both > save_intr() and disable_intr() involve a PAL call. However, the Alpha > returns the previous state whenever you set the interrupt state, which > allows you to only make 1 PAL call. Thus, I'm proposing to change > disable/enable_intr to return the previous state in addition to setting > the state. This would be a minor pessimization on i386's. WHether it is an optimization or a pessimization is very MD. It would be a major pessimization on i386's with ICUs if we put the entire interrupt state including the ICU masks in the interrrupt state. > This then removes the need for save_intr(), and > restore_intr() can stay the same. This doesn't remove the need for save_intr(). I use it in at least one place (perhaps only one :-) where I don't want to disable interrupts any more than they already are. > Another suggestion I've received is to use intrmask_t as the type > for holding interrupt state rather than u_int. OK. > Finally, another suggestion has been to fudge the names some to stick > all of these functions in one intr_* namespace. > > The end result of these changes would be this: > > intrmask_t intr_disable(void); > intrmask_t intr_enable(void); > void intr_restore(intrmask_t); I don't like names like this much. It's really a mistake to let this stuff escape from MD code. Frotunately, it hasn't escaped far yet. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message