From owner-freebsd-arch Thu Mar 15 19: 6:43 2001 Delivered-To: freebsd-arch@freebsd.org Received: from meow.osd.bsdi.com (meow.osd.bsdi.com [204.216.28.88]) by hub.freebsd.org (Postfix) with ESMTP id D06CD37B71A for ; Thu, 15 Mar 2001 19:06:39 -0800 (PST) (envelope-from jhb@FreeBSD.org) Received: from laptop.baldwin.cx (john@jhb-laptop.osd.bsdi.com [204.216.28.241]) by meow.osd.bsdi.com (8.11.2/8.11.2) with ESMTP id f2G36CG33657; Thu, 15 Mar 2001 19:06:12 -0800 (PST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Thu, 15 Mar 2001 19:06:11 -0800 (PST) From: John Baldwin To: Matthew Jacob Subject: Re: Proposal for the CPU interrupt API Cc: arch@FreeBSD.org, Matt Dillon Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 16-Mar-01 Matthew Jacob wrote: > > >> >> :I would hope it would actually disable interrupts. >> >> On all cpu's or just the current cpu? > > Undefined. This depends on the architecture. Some architectures don't have a > global interrupt lockout mechanism. Some architectures vary as to whether or > not interrupts can be directed to one CPU, broadcast to all, or only for a > specific CPU. > > I think it's safe to say that given your specific platform's interrupt > mechanism, this disable_intr disables for this CPU only, or for all. Yep. I think that on the Alpha the IPL may be shared among all CPU's or may be per-CPU but I'm not sure. On the x86 it would only be for the local CPU, but all that any calling code should depend on is that it disables interrupts for the current CPU. > This function should probably only be called from MD code. It's not very MI. > The MI code has spin && adaptive locks and should be using just those. I > can't > imagine any case with the exception of debuggers and console I/O that might > get terribly upset about this- in which case these subsystems have extensions > into MD layers anyway. Yep. The primary offenders right now are the internals of the mutex code for spin locks (which disable interrupts to prevent preemption while holding a spinlock), some MD code for dealing with floating point state and various drivers living under sys/i386/isa/. Note that on the alpha, we used the CPU mask to implement spl()'s, so intr_disable() is (and has been) functionally equivalent to splhigh(), while on x86 they were two different things. > -matt -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message