HI, people
“The driver must release any spin lock it is holding before
calling NdisQueryBuffer”—this statement is from NT2000 DDK.
but the sample “E100BEX” in DDK do not like this.
In my miniport driver, I want to obey the DDK’s rule, just
like that:
NdisReleaseSpinLock(&Adapter->Lock);
NdisQueryBuffer(…);
NdisAcquireSpinLock(&Adapter->Lock);
but , just between “NdisReleaseSpinLock” and “NdisQueryBuffer”,How
can I protect data in my Adapter’s context ? It’s seems really complex !
NdisQueryBuffer is just a wrapper around MmGetSystemAddressForMdl and I
can’t think of any reason at all why you can’t hold your spinlock while
calling this function, other than the general rule that one should try to
minimize the time a spinlock is held, and calling into some ddk functions
while holding a spinlock might not meet that criteria. Maybe somebody from
microsoft can shed some light on why this isn’t a ddk doc bug.
On the other hand, once you have your packet to query, you should be able to
release whatever lock is protecting your adapter packet queue. So perhaps
your code is a little coarse-grained in its lock usage?
-----Original Message-----
From: Yee [mailto:xxxxx@hotmail.com]
Sent: Friday, March 29, 2002 2:38 AM
To: NT Developers Interest List
Subject: [ntdev] Problem about SPIN LOCK in NDIS miniport driver
HI, people
“The driver must release any spin lock it is holding
before calling NdisQueryBuffer”—this statement is from
NT2000 DDK. but the sample “E100BEX” in DDK do not like this.
In my miniport driver, I want to obey the DDK’s rule, just
like that:
NdisReleaseSpinLock(&Adapter->Lock);
NdisQueryBuffer(…);
NdisAcquireSpinLock(&Adapter->Lock);
but , just between “NdisReleaseSpinLock” and
“NdisQueryBuffer”,How can I protect data in my Adapter’s
context ? It’s seems really complex !
Thanks for your reply.
Yee.
You are currently subscribed to ntdev as: xxxxx@stratus.com To unsubscribe send a blank email to
%%email.unsub%%