Gary, you aren’t tampering the dev_ext, are you?
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Gary G. Little
Sent: Wednesday, June 09, 2010 10:14 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] SCSIPORT context?
From having spent quite a bit of time stepping into SCSIPORT 10 years ago I
do remember there being a bit that is set when within SCSIPORT and not set
when calling from elsewhere. The operative word there being “REMEMBER” since
you are aware of where I was what I have done since then, so my memory could
have faded with age. During the time I was looking and experimenting I
recall seeing the SCSIPORT functions testing for that “context” and then
simply exiting with whatever would constitute a valid return with error
condition. Hence the only way to get in “legally” was via the timer or ISR,
but the ISR was already held by SCSIPORT.
During that time I did find another way which required a left-handed use of
WDM in DriverEntry to acquire the DeviceObject that held the DPC and
attaching a DO created in this left handed WDM side. Overall that worked
except it required some weird NULL handling in the front of the left-handed
DPC handler, but I was able to handle IO in real time instead of from the
timer.
So yeah, I would say that there really is a “context” in SCSIPORT. I think I
covered this in an article I posted here sometime around 1998 to 2000. As I
said it’s been awhile, though, so if Doran or Max or Peter pop in and say
“WRONGO!” just write it off to gray hair and Swiss cheese memory. 
Gary G. Little
H (952) 223-1349
C (952) 454-4629
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Philip D Barila
Sent: Wednesday, June 09, 2010 11:39 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] SCSIPORT context?
I’ve waffled whether this belongs on NTDEV or NTTALK, since I’m not
currently dealing with this. I decided to put it on NTDEV because it’s a
search for real understanding of a real problem real devs might run into.
List-Slaves, please relocate it if you think otherwise.
The recent discussion of virtual SCSI miniport brought up something I’ve
never quite understood about the well documented performance issues of a
virtual SCSI miniport, namely that any calls from the miniport to SCSIPORT
need to be “in the SCSIPORT context”, or something like that, with the
common solution being to use the SCSIPORT timer, which means you’re going to
incur approximately 10 ms of latency. What I don’t understand is the
definition of “the SCSIPORT context”? Does that mean any call to SCSIPORT
from the miniport must only be in response to a call from SCSIPORT? (i.e.
Any call from miniport to port must have port already in the stack?) Or
does it mean something else? Is it a thread context?
I guess my confusion stems from the “usual” meaning of context in the
kernel. It is unfortunate that the term context is so overloaded as to
offer more confusion than precision at times, when the definition is not
precisely understood. Maybe my confusion is the nature of kernel context?
Is it correct that the kernel address space is a flat address space shared
by all kernel components, and when the “context” is merely that address
space plus the current thread stack, and when the scheduler switches to a
new thread inside the kernel, it’s really just a stack swap? If so, what’s
special about the “SCSIPORT context”? SCSIPORT has to be in that stack
somewhere already before you can call into SCSIPORT from the miniport (as I
said above)?
Whatever the definition of “the SCSIPORT context”, is anyone willing to say
why it is that way?
Thanks,
Phil
Sent from Outlook through exchange using a keyboard, and a spellchecker.
Any mistakes are purely between the operator’s head and the keys.
Philip D. Barila
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
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