From owner-freebsd-current Tue Feb 26 8:38:45 2002 Delivered-To: freebsd-current@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id E840937B405; Tue, 26 Feb 2002 08:38:38 -0800 (PST) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id g1QGccQ59999; Tue, 26 Feb 2002 08:38:38 -0800 (PST) (envelope-from dillon) Date: Tue, 26 Feb 2002 08:38:38 -0800 (PST) From: Matthew Dillon Message-Id: <200202261638.g1QGccQ59999@apollo.backplane.com> To: John Baldwin Cc: Bruce Evans , Terry Lambert , Alfred Perlstein , Bosko Milekic , Seigo Tanimura , current@FreeBSD.org Subject: Re: Patch for critical_enter()/critical_exit() & interrupt assem References: 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 :.. :> cpu_critical_enter() to a null version to prevent spinlocks masking :> interrupts doesn't work very well because it is used for other things :> that really do need to mask interrupts. Having 2 levels for :> cpu_critical_enter() (on that masks normal interrupts and one that :> masks fast interrupts) would work but I think there are already too :> many levels of critical_enter()s. : :I think having the sparc-like API of intr_disable() / intr_restore() that we :used to use to fix the places that assume too many implementation details of :cpu_critical_foo() would be a good first step so that cpu_critical_foo() can be :relegated back to supporting non-preemption (and no other spinlocks) and :nothing else. : :> Bruce : :-- : :John Baldwin <>< http://www.FreeBSD.org/~jhb/ I consider this a mistake that inappropriately locks MI code into architecture-specific (MD) features, especially considering that there are only two places in the codebase that actually make this assumption right now and both can be easily fixed. It makes no sense to me to abstract out a third API (let alone making cpu_critical_*() available to the MI code) when the existing critical_*() API will do the job just fine. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message