Well, this is ugly as all h**l and I’m NOT advocating it as a general
solution but you can implement your own high-irql spinlock; someone will
probably blast me for this but here’s a sample C++ class that implements
this (you can replace the use of SYNCH_LEVEL with your Device IRQL).
/simgr
// Special spinlock suitable for use at high level…
class HighSpinLock {
public:
HighSpinLock() : m_owned(0) {}
inline void Acquire() {
KIRQL OldIrql;
if (KeGetCurrentIrql() <= SYNCH_LEVEL) {
KeRaiseIrql(SYNCH_LEVEL,&OldIrql);
// Wait for lock to be free
while (InterlockedExchange(&m_owned,1)==1)
;
// Got it - save old irql
m_oldirql = OldIrql;
}
}
inline void Release() {
if (KeGetCurrentIrql() <= SYNCH_LEVEL) {
KIRQL OldIrql = m_oldirql;
InterlockedExchange(&m_owned,0);
KeLowerIrql(OldIrql);
}
}
private:
long m_owned;
KIRQL m_oldirql;
};
-----Original Message-----
From: Mark Lobo [mailto:xxxxx@yahoo.com]
Sent: Wednesday, May 01, 2002 1:28 PM
To: NT Developers Interest List
Subject: [ntdev] Re: Help!
Well…I need to synchonize an external callback into the miniport also. And
it needs to be synchronized with the so called thin layer and the miniport
entry points . So I cannot rely on the miniports synchronization. I need
something to do this…Any way to do this? Please please help!!
Mark
“Gary G. Little” wrote:
You are in a classic rock and a hard place. The rock being Microsoft, and
like Gibraltar most likely immutable. The hardplace being that “thin layer”
that acquires and releases a lock. Hard places, by the way go away with a
big enough hammer and chisel.
I had much the same problem with an API I use to provide Windows drivers for
our fibre channel card. However … since I had to provide the code for the
acquire/release functions, and was using a private interface between he 2
drivers to call the API functionality, my solution was to write
Acquire/release as do nothing functions and since SCSI is HIGHLY synced and
serialized in its start IO functions simply call the API functions.
Your “thin layer” an also claim the resources before ScsiPortInitialoize
runs … but that causes a whole mess of other heartaches by the number.
–
Gary G. Little
xxxxx@broadstor.com mailto:xxxxx
xxxxx@inland.net mailto:xxxxx
“Mark Lobo” >
wrote in message news:xxxxx@ntdev news:xxxxx …
Guys!
Im in need of help!
Ill explain my problem in more detail here:
Im a SCSI miniport driver. Now I am supposed to be talking to this thin
layer, which does all the work of posting IOs, completions et al.
This “thin layer” requires some support, one of which is"AcquireLock" and
“ReleaseLock”, one of which is “SendIo” etc etc and the locks address is
given to the thin layer at initialization…I wont go into too much detail
here about what support it requires.
Now here is the actual problem:
Now Im at my wits end to find what to pass as a lock to this thin layer. I
cannot use a spin lock, because StartIO is called at an DIRQL, and this thin
layer calls “AcquireLock” and “ReleaseLock” every time an IO needs ro be
posted. And that messes up everything. I cannot use KeSync… because I dont
know what function to call, because the thin layer below the miniport calls
the “AcquireLock” and “ReleaseLock” and between these calls, I not supposed
know what it does . In essence, I cannot change this thin layer. Think of it
as a binary, which requires some support in the miniport to work. Is there
something like an Interrupt Spin lock? This is a Windows 2000/XP product.
How do i provide this support?
Thanks a bunch!
Mark
Do You Yahoo!?
Yahoo! http: Health - your
guide to health and wellness
—
You are currently subscribed to ntdev as: xxxxx@yahoo.com
To unsubscribe send a blank email to %%email.unsub%%
Do You Yahoo!?
Yahoo! Health http: - your
guide to health and wellness — You are currently subscribed to ntdev as:
xxxxx@stratus.com To unsubscribe send a blank email to
%%email.unsub%%</http:></http:></news:xxxxx></mailto:xxxxx></mailto:xxxxx>