The kmdf\toaster\filter sample driver in the DDK keeps track of all of
the devices it is filtering in a WDF collection. Both the collection
and the wait lock that protects it are defined as global variables in
the driver. This is true in both 6000 and 6001.
While this is a perfectly safe thing to do in this case, my inclination
would have been to store these in the driver context structure. Is
there a fundamental reason why that wasn’t done? Sometimes, these
choices are made for a specific reason, and sometimes it was “six of
one, half dozen of another.” I’m just wondering which was which here.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
No specific reason it was not putted into a WDFDRIVER context
d
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: Wednesday, February 13, 2008 3:59 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] KMDF Toaster Filter Example
The kmdf\toaster\filter sample driver in the DDK keeps track of all of
the devices it is filtering in a WDF collection. Both the collection
and the wait lock that protects it are defined as global variables in
the driver. This is true in both 6000 and 6001.
While this is a perfectly safe thing to do in this case, my inclination
would have been to store these in the driver context structure. Is
there a fundamental reason why that wasn’t done? Sometimes, these
choices are made for a specific reason, and sometimes it was “six of
one, half dozen of another.” I’m just wondering which was which here.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
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