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

John Baldwin jhb at FreeBSD.org
Wed Apr 14 08:42:59 PDT 2004


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 at FreeBSD.org>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve"  =  http://www.FreeBSD.org


More information about the cvs-src mailing list