thanks for your answer.
i think i can also deduce from your answer that i can do the same work
as in the IOCTL by a system thread or work item, is that true?
my original idea is to hardcode the PDO information in my bus driver. but, forgive my ignorance, i can’t understand the 2nd method of enumeration you mentioned, which is :
The 2nd is that you read the list from somewhere, most likely the
devnode. This way you have a flexible list of what you enumerate, but > the list has to be rich enough to describe the details of each PDO
(hardware IDs, compat IDs, instance ID, etc etc). The last half answer > is that you can use both at the same, both a fixed and dynamic list.
thanks.
WeiYu, Dong
Doron Holan дµÀ£º
(resending due to being rejected for an attachment, let’s see if this
goes through this time)
In the toaster example, the busenum.sys driver is the one that
enumerates PDOs. Toaster.sys loads on top of these PDOs. Like you
said, busenum.sys enumerates PDOs based on an IOCTL sent to it. If you
want to automatically enumerate PDOs, just do the same work as you would
in the IOCTL processing in AddDevice or IRP_MN_START_DEVICE.
Now the question becomes, what do you enumerate? Well, there are 2 (and
a half) answers to that. The first is that the list of PDOs is
hardcoded, you just know ahead of time. The 2nd is that you read the
list from somewhere, most likely the devnode. This way you have a
flexible list of what you enumerate, but the list has to be rich enough
to describe the details of each PDO (hardware IDs, compat IDs, instance
ID, etc etc). The last half answer is that you can use both at the
same, both a fixed and dynamic list.
d
---------------------------------
ÑÅ»¢Ãâ·ÑGÓÊÏä£ÖйúµÚÒ»¾øÎÞÀ¬»øÓʼþɧÈų¬´óÓÊÏä
ÑÅ»¢ÖúÊÖ£ËÑË÷¡¢É±¶¾¡¢·ÀɧÈÅ