From owner-freebsd-arch Fri Mar 16 13:58:31 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 A3ED837B71A; Fri, 16 Mar 2001 13:58:25 -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 IAA11695; Sat, 17 Mar 2001 08:58:22 +1100 Date: Sat, 17 Mar 2001 08:58:06 +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 Fri, 16 Mar 2001, John Baldwin wrote: > On 16-Mar-01 Bruce Evans wrote: > > On Thu, 15 Mar 2001, John Baldwin wrote: > >> ... 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. > > I don't think this needs to go near the ICU state, but yes, it is a minor > pessimization on i386. But on some machines it might need to go near something expensive like the ICU 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. > > If it is just the CPU status, then just intr_disable() (or disable_intr()) > will accomplish this. I don't use disable_intr() since it has the unwanted side (actually main) effect of disabling interrupts. > > It's really a mistake to let this stuff escape from MD code. Frotunately, > > it hasn't escaped far yet. > > The only somewhat MI place it is used is in the bowels of the mutex code. Any > MI code that wishes to prevent preemption should use a spinlock instead of > disabling interrupts manually now. It is also used in (non-broken) drivers that use fast interrupt handlers. The broken sio and cy drivers in -current assume that spinlocks disable all interrupts (on the current CPU). This will be fixed. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message