What amazes me is that a piece of crap code I wrote in 2002 is still being
discussed. The OP posited the question because he’s been tasked to make the
driver work on AMD64. Frankly what needs to be done is, as I said earlier,
scrap the current implementations of the bus and peer to peer drivers, and
write them using KMDF.
Oh well …
Gary G. Little
H (952) 223-1349
C (952) 454-4629
xxxxx@comcast.net
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@osr.com
Sent: Saturday, February 27, 2010 9:10 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] compiler intrinsic ExInterlockedRemoveEntryList
Huh?
I’m not sure I understand the question, so I’ll take it as face value and
answer that.
Because the operations aren’t equivalent. KeRaiseIrql does what the name
suggests… it raises the IRQL and nothing more. KeSynchronizeExecution
acquires the interrupt spin lock (which implies raising the IRQL to the
driver’s synchronize IRQL). Both useful operations, but not the same.
Consider that you could (COULD, I’m not recommending this, but it’s entirely
possible) build your own locking primitive using a the IRQL of your choice
and an interlocked bit test and set operation (or interlocked exchange or…
you pick one).
You’re asserting that KeRaiseIrql to IRQL HIGH_LEVEL is special cased in
Windows? Are you sure of this?
Peter
OSR
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
__________ Information from ESET Smart Security, version of virus signature
database 4900 (20100227) __________
The message was checked by ESET Smart Security.
__________ Information from ESET Smart Security, version of virus signature
database 4900 (20100227) __________
The message was checked by ESET Smart Security.