Lets’s say i create a device interface for an Ethernet Card (let’s call it Device A). I come along and plug in another ethernet card (Device B).
How can someone who registers for device interface notifications know which device is which? More so, how can I get the instance ID?
I’m asking this because I am using MF.sys to create 4 components for 1 multifunction device. The device is not really multifunction, but more so, 4 components based on the 4 bars of the device. One of the components (lets say BAR0) registers for device notifications for another component (lets say BAR1). How can the component know the change was made for the component instance its looking for, and not another component on another device instance?
Identity is tricky. In your case you would have to have some private channel to the other instance and ask it who it is (Again custom) and go from there. Instance id won’t help you much since you really need to find a common parent and the sibling instance id won’t give you any info on the parent
d
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
Sent: Wednesday, May 1, 2013 9:31 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Device Interface for multiple Device Instances
Lets’s say i create a device interface for an Ethernet Card (let’s call it Device A). I come along and plug in another ethernet card (Device B).
How can someone who registers for device interface notifications know which device is which? More so, how can I get the instance ID?
I’m asking this because I am using MF.sys to create 4 components for 1 multifunction device. The device is not really multifunction, but more so, 4 components based on the 4 bars of the device. One of the components (lets say BAR0) registers for device notifications for another component (lets say BAR1). How can the component know the change was made for the component instance its looking for, and not another component on another device instance?
NTDEV is sponsored by OSR
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
xxxxx@gmail.com wrote:
Lets’s say i create a device interface for an Ethernet Card (let’s call it Device A). I come along and plug in another ethernet card (Device B).
How can someone who registers for device interface notifications know which device is which? More so, how can I get the instance ID?
I’m asking this because I am using MF.sys to create 4 components for 1 multifunction device. The device is not really multifunction, but more so, 4 components based on the 4 bars of the device. One of the components (lets say BAR0) registers for device notifications for another component (lets say BAR1). How can the component know the change was made for the component instance its looking for, and not another component on another device instance?
There are several answers to this question, although my first
inclination is to ask the “why” question. It’s unusual for a child
device to need to contact one of its peers.
In user mode, the answer is “you can’t”. Every time you get a
notification, you have to go rescan the devices using the SetupDi APIs,
and compare the new list with the list you got last time. That tells
you what changed. The SetupDi APIs can return the device instance ID
to you.
In kernel mode, you don’t have that option, but you have other options.
GUIDs don’t cost anything. If the devices have different functionality,
why not have each device interface register its own interface? Then you
can scan for them individually. You could also keep a collection in a
driver global (gasp!) that tracks device objects and their parent device
objects. That would let you do look ups pretty easily.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
I get what you guys are saying. However, since MF.sys is the arbitrator, wouldn’t all their parents be the FDO of MF.sys, meaning they would all be the same?
| DEVICE0 | | DEVICE1 |
| MF.SYS | | MF.SYS |
|COMP1|COMP2 | |COMP1|COMP2 |
The device keys in the registry have the instance ID within the key, that may also me useful. Any other hints or tips?
While mf.sys is the common parent, each device, 1 and 2, will have its own mf.sys created device object as the role of the parent. One driver object, many devices.
d
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
Sent: Wednesday, May 1, 2013 10:35 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Device Interface for multiple Device Instances
I get what you guys are saying. However, since MF.sys is the arbitrator, wouldn’t all their parents be the FDO of MF.sys, meaning they would all be the same?
| DEVICE0 | | DEVICE1 |
| MF.SYS | | MF.SYS |
|COMP1|COMP2 | |COMP1|COMP2 |
The device keys in the registry have the instance ID within the key, that may also me useful. Any other hints or tips?
NTDEV is sponsored by OSR
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
Ok. So I would assume that calls to WdfDeviceWdmGetAttachedDevice(device), where device is the FDO I created in my driver would give me the FDO of the PARENT device. However, things get a bit tricky once I start looking into the native WDM DeviceObject.
Are there any better ways to verify the parent?? MF.sys, keeping in mind that there may be filters stuffed in between them?
Actually, easiest, and best option would be to use the PCI slot number. Is there a way to get this in WDF?
WdfDeviceWdmGetAttachedDevice gives you the device below in you in the stack that you are attached to. As the fdo, that is typically the PDO (not the FDO of the parent stack which enumerated that PDO). It could also point to a lower filter if one is installed.
d
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
Sent: Thursday, May 2, 2013 1:11 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Device Interface for multiple Device Instances
Ok. So I would assume that calls to WdfDeviceWdmGetAttachedDevice(device), where device is the FDO I created in my driver would give me the FDO of the PARENT device. However, things get a bit tricky once I start looking into the native WDM DeviceObject.
Are there any better ways to verify the parent?? MF.sys, keeping in mind that there may be filters stuffed in between them?
NTDEV is sponsored by OSR
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
Thanks Doron. So clearly this is the wrong thing to do, since a filter driver can sit in between anywhere (as is right now when I’m running Driver Verifier).
The best decision I can think of is comparing virtual addresses from each of the BARs. This however, won’t work if in later versions of windows, BARs are not sequential virtual addresses. Am I correct in thinking this?
Can a PCI device driver in Windows determine his own BUS:DEV:FUNC? If so, DEVICE1:COMP1 in your example could query each COMP2 and ask it what it’s BUS:DEV:FUNC is. Whichever COMP2 responds with a BUS:DEV:FUNC that matches DEVICE1:COMP1 would then be part of DEVICE1.
The fact that there might be a filter in the way is inconsequential. If you want the PDO, you can get that with WdfDeviceWdmGetPhysicalDeviceObject. Is there anything in the config space that is unique per physical instance? If so, you can read that. Otherwise, if there is writable space somewhere in there, query the value and if zero, write out a random number. If you find the random number you know a sibling has started and you can find it by enumerating its instances and correlating
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
Sent: Thursday, May 2, 2013 3:33 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Device Interface for multiple Device Instances
Thanks Doron. So clearly this is the wrong thing to do, since a filter driver can sit in between anywhere (as is right now when I’m running Driver Verifier).
The best decision I can think of is comparing virtual addresses from each of the BARs. This however, won’t work if in later versions of windows, BARs are not sequential virtual addresses. Am I correct in thinking this?
NTDEV is sponsored by OSR
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
TraceEvents(
TRACE_LEVEL_INFORMATION,
DBG_PNP,
“PDO(0x%p) FDO(0x%p), Lower(0x%p)\n”,
WdfDeviceWdmGetPhysicalDevice(device),
WdfDeviceWdmGetDeviceObject(device),
WdfDeviceWdmGetAttachedDevice(device)
);
Isn’t PDO and LOWER equal to each other in this example?? I feel like i’m missing something
Not sure if the PDOs that MF.sys enumerates will give you the pci slot number because technically that is a property of the parent stack and not propagated to the children.
d
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
Sent: Thursday, May 2, 2013 1:46 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Device Interface for multiple Device Instances
Actually, easiest, and best option would be to use the PCI slot number. Is there a way to get this in WDF?
NTDEV is sponsored by OSR
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
xxxxx@gmail.com wrote:
TraceEvents(
TRACE_LEVEL_INFORMATION,
DBG_PNP,
“PDO(0x%p) FDO(0x%p), Lower(0x%p)\n”,
WdfDeviceWdmGetPhysicalDevice(device),
WdfDeviceWdmGetDeviceObject(device),
WdfDeviceWdmGetAttachedDevice(device)
);
Isn’t PDO and LOWER equal to each other in this example?? I feel like i’m missing something
Only if there are no lower filters.
upper filter DO
upper filter DO
FDO <– WdfDeviceWdmGetDeviceObject
lower filter DO <– WdfDeviceWdmGetAttachedDevice
lower filter DO
PDO <– WdfDeviceWdmGetPhysicalDevice
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Alas, how can I get FDO that created the PDO asssociated with my device? Whether that is PCI.sys or MF.sys
xxxxx@gmail.com wrote:
Alas, how can I get FDO that created the PDO asssociated with my device? Whether that is PCI.sys or MF.sys
You can get your own PDO. In that DEVICE_OBJECT, the AttachedDevice
field has the DO for the top of the next stack. It might be an FDO, or
it might be an upper filter driver for that FDO, but that’s usually what
you want.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
On 03-May-2013 02:54, xxxxx@gmail.com wrote:
Alas, how can I get FDO that created the PDO asssociated with my device? Whether that is PCI.sys or MF.sys
It looks like a self-inflicted problem. Why use mf.sys at all?
Why to create several devices if they are not independent?
You could just make a simple PCI driver and register 4 interface
instances on each card, so the app could enumerate all the widgets.
– pa
The problem with this approach is that it fails in certain hot-plug scenarios where the bus number will change at run time. Most of the time, no problem. Then your driver gets added as part of, for example, a Thunderbolt hierarchy, and the next time you see it the bus number is different.
Please don’t depend on knowing your bus number. If you need durable representations of a device, use the Instance ID that’s available through the IoGetDeviceProperty stuff.
- Jake Oshins
Windows Kernel Team
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@hotmail.com
Sent: Thursday, May 2, 2013 3:51 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Device Interface for multiple Device Instances
Can a PCI device driver in Windows determine his own BUS:DEV:FUNC? If so, DEVICE1:COMP1 in your example could query each COMP2 and ask it what it’s BUS:DEV:FUNC is. Whichever COMP2 responds with a BUS:DEV:FUNC that matches DEVICE1:COMP1 would then be part of DEVICE1.
NTDEV is sponsored by OSR
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
What, exactly, would you do with the PCI FDO that created your PDO? What operation do you think that affords?
Curiously,
Jake Oshins
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
Sent: Thursday, May 2, 2013 4:54 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Device Interface for multiple Device Instances
Alas, how can I get FDO that created the PDO asssociated with my device? Whether that is PCI.sys or MF.sys
NTDEV is sponsored by OSR
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
Jake,
That’s a very good point about hot-plug scenarios. An alternative would be to keep going until you reach the root port and get it’s BUS:DEV:FUNC as that will be fixed.
Could you share how a person would get the Instance ID? I don’t see a DEVICE_REGISTRY_PROPERTY appropriate to call IoGetDeviceProperty with to get this information.