Date: Wed, 14 Apr 2004 11:05:43 -0400 From: John Baldwin <jhb@FreeBSD.org> To: Bill Paul <wpaul@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_ntoskrnl.c src/sys/dev/if_ndis if_ndis.c if_ndisvar.h Message-ID: <200404141105.43663.jhb@FreeBSD.org> In-Reply-To: <200404140748.i3E7m4HV067995@repoman.freebsd.org> References: <200404140748.i3E7m4HV067995@repoman.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wednesday 14 April 2004 03:48 am, Bill Paul wrote: > wpaul 2004/04/14 00:48:03 PDT > > FreeBSD src repository > > Modified files: > 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_ntoskrnl.c > sys/dev/if_ndis if_ndis.c if_ndisvar.h > Log: > Continue my efforts to imitate Windows as closely as possible by > attempting to duplicate Windows spinlocks. Windows spinlocks differ > from FreeBSD spinlocks in the way they block preemption. FreeBSD > spinlocks use critical_enter(), which masks off _all_ interrupts. > This prevents any other threads from being scheduled, but it also > prevents ISRs from running. In Windows, preemption is achieved by > raising the processor IRQL to DISPATCH_LEVEL, which prevents other > threads from preempting you, but does _not_ prevent device ISRs > from running. (This is essentially what Solaris calls dispatcher > locks.) The Windows spinlock itself (kspin_lock) is just an integer > value which is atomically set when you acquire the lock and atomically > cleared when you release it. > > FreeBSD doesn't have IRQ levels, so we have to cheat a little by > using thread priorities: normal thread priority is PASSIVE_LEVEL, > lowest interrupt thread priority is DISPATCH_LEVEL, highest thread > priority is DEVICE_LEVEL (PI_REALTIME) and critical_enter() is > HIGH_LEVEL. In practice, only PASSIVE_LEVEL and DISPATCH_LEVEL > matter to us. The immediate benefit of all this is that I no > longer have to rely on a mutex pool. > > 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. -- John Baldwin <jhb@FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200404141105.43663.jhb>