Re: How to check if a spin lock has been freed or released?
- From: "Stephan Wolf [MVP]" <stewo68@xxxxxxxxxxx>
- Date: 28 Jan 2006 04:41:45 -0800
Bill Paul wrote:
> Unfortunately, people _do_ make assumptions. Developers assume that
> they're writing Windows drivers, not NDIS drivers.
Hmm, well, it would seem it is not the poeple but *you* who is making
assumptions. Both on NDIS as well as on if or how other people make
assumptions.
One thing a chief developer I worked for taught me was "programming
errors are *always* the result of false assumptions." Think of it a
little. It has turned out to be true for me during the last 15 years.
> They make coding
> mistakes when writing their NDIS drivers and yet they assume everything
> is fine because the existing Windows NDIS implementation lets them
> get away with it. And one could argue Microsoft has made the same
> assumptions since it doesn't instrument the NdisFreeSpinLock() routine
> so that driver verifier can catch these mistakes.
Right.
> Yes, I know NDIS was supposed to be platform-independent. Novell Netware
> was another one of the OSes that supported it. But right now, there's
> only one NDIS implementation in common use, and that's the one Microsoft
> is shipping in Windows 2K/XP/2K3.
Well, some (if not many) people still use ME/98/95 based Windows. Also,
Windows CE is widely used in embedded systems.
> There's another class of potential error here, by the way. I also ran
> across one driver that would do an NdisAllocateSpinLock() in its
> DriverEntry() routine, and then do NdisFreeSpinLock() in its MiniportHalt()
> routine. Presumeably the spinlock was designed to guard data that was
> global across all adapter instances created by the driver. The problem of
> course is that MiniportHalt() can be called repeatedly once the driver
> is loaded, so the result is a spinlock that's created only once but
> destroyed many times. Since NdisAllocateSpinLock() doesn't actually
> allocate anything, and since NdisFreeSpinLock() is a no-op, the bug ends
> up being harmless (on Windows NT/2K/XP/2K3), except insofar as it doesn't
> discourage the developer from writing sloppy code.
Exactly. IIRC, however, in Windows CE, NdisFreeSpinLock() *does*
actually do something, i.e. it is not a no-op.
Sure the NdisAllocateSpinLock()/NdisFreeSpinLock() either should be in
DriverEntry()/UnloadHandler() (the latter can be registered by
NdisMRegisterUnloadHandler()) or it should be in
MiniportInitialize()/MiniportHalt().
Still I would not make any assumptions on how NDIS functions are
actually implemented. AFAIK, there even exists a NDIS Wrapper for x86
Linux, which enables Windows NDIS miniport drivers (binary file) to run
under x86 Linux. You assumptions on spinlocks probably fail for this
scenario.
More, it was common to have binary compatible NDIS miniport drivers for
all of W95/W98/WME/NT4/W2K until MS added some incompatible features
(see also http://www.wd-3.com/031504/NDISCompile.htm).
Stephan
.
- Follow-Ups:
- Re: How to check if a spin lock has been freed or released?
- From: Bill Paul
- Re: How to check if a spin lock has been freed or released?
- From: Skywing
- Re: How to check if a spin lock has been freed or released?
- References:
- How to check if a spin lock has been freed or released?
- From: Barry
- Re: How to check if a spin lock has been freed or released?
- From: Bill Paul
- Re: How to check if a spin lock has been freed or released?
- From: Stephan Wolf [MVP]
- Re: How to check if a spin lock has been freed or released?
- From: Bill Paul
- How to check if a spin lock has been freed or released?
- Prev by Date: Re: Is any difference between CL/LINK in SDK and that in DDK?
- Next by Date: Who is the parent? (IRP_MJ_INTERNAL_DEVICE_CONTROL)
- Previous by thread: Re: How to check if a spin lock has been freed or released?
- Next by thread: Re: How to check if a spin lock has been freed or released?
- Index(es):
Relevant Pages
|
