Hello, I am new to windows DDK and I am studying the examples. There is one thing that I don?t understand regarding osrusbfx2?s default IO queue:
The driver does not specify any execution level for the queue, and the callback (OsrFxEvtIoDeviceControl()) is pageable. I assume this works because osrusbfx2 is at the top of its driver stack, (i.e. the call back function will always be invoked at IRQL = PASSIVE_LEVEL).
Is this assumption correct ?
Would the design of osrusbfx2 still be valid if one would write/add an upper filter driver to osrusbfx2 ? i.e. osrusbfx2 would no longer be at the top of its driver stack, which no longer guaranty OsrFxEvtIoDeviceControl() to be invoked at IRQL = PASSIVE_LEVEL?
Thank you in advance for the help; This is so obvious that I must be missing something.
- correct
- as a filter you must follow the rules of the stack you are filtering, you cannot change the rules unless you can change all drivers implementing those rules, so it would be up to the filter driver to make sure it sends io at passive level.
D
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@live.com
Sent: Wednesday, October 15, 2014 9:05 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] WDK 8.1 osrusbfx2 scalability issue question
Hello, I am new to windows DDK and I am studying the examples. There is one thing that I don?t understand regarding osrusbfx2?s default IO queue:
The driver does not specify any execution level for the queue, and the callback (OsrFxEvtIoDeviceControl()) is pageable. I assume this works because osrusbfx2 is at the top of its driver stack, (i.e. the call back function will always be invoked at IRQL = PASSIVE_LEVEL).
Is this assumption correct ?
Would the design of osrusbfx2 still be valid if one would write/add an upper filter driver to osrusbfx2 ? i.e. osrusbfx2 would no longer be at the top of its driver stack, which no longer guaranty OsrFxEvtIoDeviceControl() to be invoked at IRQL = PASSIVE_LEVEL?
Thank you in advance for the help; This is so obvious that I must be missing something.
NTDEV is sponsored by OSR
Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
OSR is HIRING!! See http://www.osr.com/careers
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
Thank you for the quick reply. so this means that if you are writing a filter driver for a function driver you don’t have the source code for, then you must be cautious and send/forward requests at passive level?
wouldn’t it be preferable to always define the execution level in a driver so that upper filters don’t have to make any assumptions?
It isn’t that you must be cautious, it is that you must understand the rules of the stack. Usually pretty deeply to write a proper filter. FDO drivers are not writing their driver to make filtering simple, they are writing their code to make the FDO functional and simple.
d
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@live.com
Sent: Wednesday, October 15, 2014 9:42 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] WDK 8.1 osrusbfx2 scalability issue question
Thank you for the quick reply. so this means that if you are writing a filter driver for a function driver you don’t have the source code for, then you must be cautious and send/forward requests at passive level?
wouldn’t it be preferable to always define the execution level in a driver so that upper filters don’t have to make any assumptions?
NTDEV is sponsored by OSR
Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
OSR is HIRING!! See http://www.osr.com/careers
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