Driver to driver communication in WDF

Shane_Corbin · July 3, 2008, 2:18pm

I’ve search the OSR repositories and found a couple WDM approaches for driver to driver communication. Namely the following articles:
Beyond IRPs: Driver to Driver Communications
http://www.osronline.com/article.cfm?id=177

Buddy Drivers - Methods for Driver to Driver Communication
http://www.osronline.com/article.cfm?id=24

However, I was curious if there are WDF mechanisms that I should entertain before trying either approach from the above articles.

The problem I’m trying to solve is that driver A has access to two registers that would be highly useful in driver B. Ideally I’d like to export a couple functions that retrieve the needed data. However, this isn’t something I’ve attempted in device drivers for Windows.

Are there preferred WDF mechanisms for doing such a thing?

Doron_Holan · July 3, 2008, 2:27pm

You cannot write a pure export driver in WDF, writing a hybrid driver that is loaded on demand by pnp as well as exporting functions is a nightmare in terms of lifetime. The easiest way to do this is to have Driver B open a handle to Driver A and send a IRP_MJ_PNP/IRP_MN_QUERY_INTERFACE w/your own custom interface and provide these functions…BUT, I do not think that is the right answer either. Why? b/c driver B has no idea about A’s power state and if B is given unmitigated access to these registers, it could try to touch them after A has turned off the device (either through idle in S0 or during an Sx transition). The best way to “export” this to define a couple of internal IOCTLs and have B send them to A. A will fwd these IOCTLs into a power managed queue (if the top level dispatching queue is not power managed) and this will take care of coordinating an external driver trying to touch registers with A’s power state

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@hotmail.com
Sent: Thursday, July 03, 2008 11:16 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Driver to driver communication in WDF

I’ve search the OSR repositories and found a couple WDM approaches for driver to driver communication. Namely the following articles:
Beyond IRPs: Driver to Driver Communications
http://www.osronline.com/article.cfm?id=177

Buddy Drivers - Methods for Driver to Driver Communication
http://www.osronline.com/article.cfm?id=24

However, I was curious if there are WDF mechanisms that I should entertain before trying either approach from the above articles.

The problem I’m trying to solve is that driver A has access to two registers that would be highly useful in driver B. Ideally I’d like to export a couple functions that retrieve the needed data. However, this isn’t something I’ve attempted in device drivers for Windows.

Are there preferred WDF mechanisms for doing such a thing?

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

Tim_Roberts · July 3, 2008, 2:37pm

Doron Holan wrote:

…The best way to “export” this to define a couple of internal IOCTLs and have B send them to A. A will fwd these IOCTLs into a power managed queue (if the top level dispatching queue is not power managed) and this will take care of coordinating an external driver trying to touch registers with A’s power state

ExCreateCallback/ExNotifyCallback is another simple, low-overhead
mechanism for this kind of communication, although it’s not wrapped by KMDF.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

Shane_Corbin · July 3, 2008, 3:04pm

The best way to “export” this to define a couple of internal
IOCTLs and have B send them to A.

I’m not sure I understand what you mean by B ‘sending’ the internal IOCTLs to A.

Secondly, it sounds like I would still need to do some sort of PNP notification from one driver to the other to let it know that it’s up and ready for device io. Are there any graceful ways that the WDF can help with this?

I’m still pretty green to driver writing in Windows, but I’m trying to soak as much in as possible. It just doesn’t really sink in until you get your hands dirty. I’ve got lots to learn.

Thanks!

Doron_Holan · July 3, 2008, 3:44pm

> I’m not sure I understand what you mean by B ‘sending’ the internal IOCTLs to A.
B opens up a handle to A and then builds a PIRP, formats it as an internal IOCTL and sends it to A. If B is also a WDF driver, it can create and then open a WDFIOTARGET, allocate a WDFREQUEST, format it (WdfIoTargetFormatRequestForInternalIoctl) and send it. Alternatively you can send it synchronously (WdfIoTargetSendInternalIoctlSynchronously)

Secondly, it sounds like I would still need to do some sort of PNP notification from one driver to the other to let it know that it’s up and ready for device io. Are there any graceful ways that the WDF can help with this?
In driver A you create a device interface (WdfDeviceCreateDeviceInterface), this can be your own custom GUID. In driver B you register for device interface notifications (IoRegisterPlugPlayNotification). This will give you the name to open device A by.

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@hotmail.com
Sent: Thursday, July 03, 2008 12:03 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Driver to driver communication in WDF