From owner-cvs-all@FreeBSD.ORG Thu Apr 15 11:44:53 2004 Return-Path: Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 94B9C16A4CE for ; Thu, 15 Apr 2004 11:44:53 -0700 (PDT) Received: from mail4.speakeasy.net (mail4.speakeasy.net [216.254.0.204]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4C6C943D48 for ; Thu, 15 Apr 2004 11:44:51 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Received: (qmail 7048 invoked from network); 15 Apr 2004 18:44:50 -0000 Received: from dsl027-160-063.atl1.dsl.speakeasy.net (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) encrypted SMTP for ; 15 Apr 2004 18:44:50 -0000 Received: from 10.50.40.205 (gw1.twc.weather.com [216.133.140.1]) by server.baldwin.cx (8.12.10/8.12.10) with ESMTP id i3FIigl5002029; Thu, 15 Apr 2004 14:44:48 -0400 (EDT) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: wpaul@FreeBSD.ORG (Bill Paul) Date: Thu, 15 Apr 2004 14:34:20 -0400 User-Agent: KMail/1.6 References: <20040414220453.7806316A4CF@hub.freebsd.org> In-Reply-To: <20040414220453.7806316A4CF@hub.freebsd.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200404151434.20428.jhb@FreeBSD.org> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on server.baldwin.cx cc: cvs-src@FreeBSD.org cc: src-committers@FreeBSD.org cc: cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/compat/ndis hal_var.h kern_ndis.c ndis_var.h ntoskrnl_var.h pe_var.h subr_hal.c subr_ndis.c subr_ntoskrn X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Apr 2004 18:44:53 -0000 On Wednesday 14 April 2004 06:04 pm, Bill Paul wrote: > > > Now, I'm sure many people will be seized by the urge to criticize > > > me for doing an end run around our own spinlock implementation, but > > > it makes more sense to do it this way. Well, it does to me anyway. > > > > If you don't use atomic ops with memory barriers somewhere (like the > > mutex implementation does) then NDIS won't work on SMP. Really, IRQL is > > basically spl()s, and we don't use an spl-like model anymore. Just using > > mutexes for locking should give you all the protection you need. > > Protection is all well and good, but I need to provide the right semantics > as well. I need to fool the drivers into thinking they can depend on the > usual Windows behavior, and make it easy to use the Windows data types, > and it's a pain in the butt to do that with regular mutexes. > > And besides, I wanna. > > Now, from subr_ntoskrnl.c: > > __stdcall void > ntoskrnl_lock_dpc(/*lock*/ void) > { > kspin_lock *lock; > > __asm__ __volatile__ ("" : "=c" (lock)); > > while (atomic_cmpset_int((volatile u_int *)lock, 0, 1) == 0) > /* do nothing */; > > return; > } > > __stdcall void > ntoskrnl_unlock_dpc(/*lock*/ void) > { > kspin_lock *lock; > > __asm__ __volatile__ ("" : "=c" (lock)); > > atomic_cmpset_int((volatile u_int *)lock, 1, 0); > > return; > } > > These two routines do the actual work of acquiring and releasing the > lock (they map to KefAcquireSpinLockAtDpcLevel() and > KefReleaseSpinLockFromDpcLevel). Are you saying the former routine > should use atomic_cmpset_acq_int() and the latter atomic_cmpset_rel_int()? Yes. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org