From owner-freebsd-arch Thu Mar 15 18:46:42 2001 Delivered-To: freebsd-arch@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 2309337B718; Thu, 15 Mar 2001 18:46:40 -0800 (PST) (envelope-from mjacob@feral.com) Received: from beppo (beppo [192.67.166.79]) by feral.com (8.9.3/8.9.3) with ESMTP id SAA20606; Thu, 15 Mar 2001 18:46:41 -0800 Date: Thu, 15 Mar 2001 18:46:38 -0800 (PST) From: Matthew Jacob Reply-To: mjacob@feral.com To: Matt Dillon Cc: John Baldwin , arch@FreeBSD.ORG Subject: Re: Proposal for the CPU interrupt API In-Reply-To: <200103160242.f2G2gNS54923@earth.backplane.com> 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 > > :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. 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. -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message