From owner-freebsd-current Fri Mar 8 3:16:30 2002 Delivered-To: freebsd-current@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 4FD3137B400; Fri, 8 Mar 2002 03:16:26 -0800 (PST) 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 WAA10544; Fri, 8 Mar 2002 22:16:14 +1100 Date: Fri, 8 Mar 2002 22:16:56 +1100 (EST) From: Bruce Evans X-X-Sender: To: Jake Burkholder Cc: Robert Watson , Matthew Dillon , FreeBSD current users Subject: Re: Patch for critical_enter()/critical_exit() & interrupt assem In-Reply-To: <20020307205844.C12044@locore.ca> Message-ID: <20020308205130.V3894-100000@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, 7 Mar 2002, Jake Burkholder wrote: > Apparently, On Thu, Mar 07, 2002 at 05:21:21PM -0500, > Robert Watson said words to the effect of; > > The primary objections I've seen from Jake, and he posted them as part of > > the earlier thread prior to the commit, was that the API changes proposed > > by Matt don't make sense for the sparc64 implementation, uni-processor or > > multi-processor, and that while these changes might be appropriate for > > i386, he wanted to see the APIs set up in such a way that the differences > > in architectures were hidden in the MD code. This suggests working some > > more on the API before moving on, and my reading of earlier posts in the > > thread from John was that that was what he had in mind also. > > Yes. What I would like and what I mentioned before is for this to be > hidden behind cpu_critical_enter/exit. Specifically, cpu_critical_enter > would be a null macro for i386, which would turn critical_enter into > just an increment, as Matt wanted. cpu_critical_exit would do all the > magic of unpending interrupts. The reason for this is that I would > like to see critical_exit handled any pending preemptions for a thread. > We do not yet know exactly how this will work so I would like this to be > done in MI code to start with. The code must not make assumptions that are > not valid on all platforms. This is easiest if they use the same code. > This is not about duplication of code in several MD files. There must be something that disables all interrupts, since fast interrupt handlers and other very-time-critical code needs to disable all interrupts. That something must have an MI interface, and it is currently named cpu_critical_enter(), so cpu_critical_enter() (or whatever it is named) must not be null. Your scheme basically needs another level of criticality between cpu_critical and plain critical (currently, criticality is not very hierarchial, but it should be). This level and the plain level must not mask fast interrupts (if any), since masking interrupts in not-very-critical code like the scheduler makes them non-fast. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message