How to add new interface and functionality to the existing device stack

Michal_Vodicka-2 · January 29, 2008, 2:45pm

I can miss something basic about PnP but can’t find a good way how to solve following problem. There is a hw device which has its own function driver supplied by 3rd party vendor. It exposes device interface standard way. Now there is a requirement to write a driver which uses the existing driver (i.e. doesn’t replace it) to implement its own functionality and exposes quite different interface. The requirement is that new driver is loaded automatically by PnP when the device is plugged in. PnP loads original function driver, it registers its interface and then new driver should be also loaded. Both interfaces should be available for its clients at once.

I can imagine to install new driver as upper filter of existing one. But it is suboptimal because new driver would receive all traffic directed to the original driver and also, it doesn’t seem as correct design to me. The new driver is client of the original one, not the filter.

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

Don_Burn_1 · January 29, 2008, 2:49pm

Michal,

Except for the requirement of PnP loading the new driver after the
original (if this is a requirement), one can easily do this with a root
enumerated PnP driver, that uses IoRegisterPlugPlayNotification to know when
a new interface is available, then creates its own interface to use that
one.

–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply

“Michal Vodicka” wrote in message
news:xxxxx@ntdev…
I can miss something basic about PnP but can’t find a good way how to solve
following problem. There is a hw device which has its own function driver
supplied by 3rd party vendor. It exposes device interface standard way. Now
there is a requirement to write a driver which uses the existing driver
(i.e. doesn’t replace it) to implement its own functionality and exposes
quite different interface. The requirement is that new driver is loaded
automatically by PnP when the device is plugged in. PnP loads original
function driver, it registers its interface and then new driver should be
also loaded. Both interfaces should be available for its clients at once.

I can imagine to install new driver as upper filter of existing one. But it
is suboptimal because new driver would receive all traffic directed to the
original driver and also, it doesn’t seem as correct design to me. The new
driver is client of the original one, not the filter.

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

Doron_Holan · January 29, 2008, 3:45pm

Is the requirement that your driver load on demand when the other device appears created by the fact that you do not want the new device interface to always be present? E.g. that it is only available when the 3rd party driver is present? If so, as don suggested, you can always be a root enumerated device and then selectively enable/disable your new device interface based on the presence of the 3rd party device stack.

OTOH, being a filter on top of the 3rd part device stack would be my initial stab at a solution. So what if you see all the traffic for the 3rd party device. IoSkip/IoCall is not going to add any noticeable overhead.

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Don Burn
Sent: Tuesday, January 29, 2008 11:49 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] How to add new interface and functionality to the existing device stack

Michal,

Except for the requirement of PnP loading the new driver after the
original (if this is a requirement), one can easily do this with a root
enumerated PnP driver, that uses IoRegisterPlugPlayNotification to know when
a new interface is available, then creates its own interface to use that
one.

–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply

“Michal Vodicka” wrote in message
news:xxxxx@ntdev…
I can miss something basic about PnP but can’t find a good way how to solve
following problem. There is a hw device which has its own function driver
supplied by 3rd party vendor. It exposes device interface standard way. Now
there is a requirement to write a driver which uses the existing driver
(i.e. doesn’t replace it) to implement its own functionality and exposes
quite different interface. The requirement is that new driver is loaded
automatically by PnP when the device is plugged in. PnP loads original
function driver, it registers its interface and then new driver should be
also loaded. Both interfaces should be available for its clients at once.

I can imagine to install new driver as upper filter of existing one. But it
is suboptimal because new driver would receive all traffic directed to the
original driver and also, it doesn’t seem as correct design to me. The new
driver is client of the original one, not the filter.

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

—
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

Ray_Trent · January 29, 2008, 4:04pm

I agree with Doron that the filter seems like the most “Windows”-ish way
of doing it and that it won’t add significant overhead.

If you *really, really, really* have to have something like you
described, and can’t even allow the kernel driver to be loaded unless
the other driver is loaded, I think it’s technically possible, but
almost certainly not worth the trouble.

(I don’t recommend this, but in case you’re curious: I think it’s
possible to have a user mode service that registers for interface
notification on the 3rd party driver’s interface, let WMI start that
service automagically when the interface appears, and have the service
demand start your driver… ugh… no, double ugh)

Doron Holan wrote:

Is the requirement that your driver load on demand when the other device appears created by the fact that you do not want the new device interface to always be present? E.g. that it is only available when the 3rd party driver is present? If so, as don suggested, you can always be a root enumerated device and then selectively enable/disable your new device interface based on the presence of the 3rd party device stack.

OTOH, being a filter on top of the 3rd part device stack would be my initial stab at a solution. So what if you see all the traffic for the 3rd party device. IoSkip/IoCall is not going to add any noticeable overhead.

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Don Burn
Sent: Tuesday, January 29, 2008 11:49 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] How to add new interface and functionality to the existing device stack

Michal,

Except for the requirement of PnP loading the new driver after the
original (if this is a requirement), one can easily do this with a root
enumerated PnP driver, that uses IoRegisterPlugPlayNotification to know when
a new interface is available, then creates its own interface to use that
one.

–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply

“Michal Vodicka” wrote in message
> news:xxxxx@ntdev…
> I can miss something basic about PnP but can’t find a good way how to solve
> following problem. There is a hw device which has its own function driver
> supplied by 3rd party vendor. It exposes device interface standard way. Now
> there is a requirement to write a driver which uses the existing driver
> (i.e. doesn’t replace it) to implement its own functionality and exposes
> quite different interface. The requirement is that new driver is loaded
> automatically by PnP when the device is plugged in. PnP loads original
> function driver, it registers its interface and then new driver should be
> also loaded. Both interfaces should be available for its clients at once.
>
> I can imagine to install new driver as upper filter of existing one. But it
> is suboptimal because new driver would receive all traffic directed to the
> original driver and also, it doesn’t seem as correct design to me. The new
> driver is client of the original one, not the filter.
>
> Best regards,
>
> Michal Vodicka
> UPEK, Inc.
> [xxxxx@upek.com, http://www.upek.com]
>
>
>
>
> —
> 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
>

–
Ray
(If you want to reply to me off list, please remove “spamblock.” from my
email address)

Michal_Vodicka-2 · January 29, 2008, 4:07pm

Don,

this is what I have as a backup solution which I don’t like too much I don’t know how many original devices will be installed on the system. So, if I understand correctly, root enumerated driver would have to create (be installed for) several dummy devices and when a new original device appears, create/enable new interface for one of these devices. Is it correct?

In turn it looks like virtual bus. Maybe it’d be also a solution but it seems unnecessarily complicated to me. I hoped there is something simpler.

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

From: xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com] on behalf of Don Burn[SMTP:xxxxx@acm.org]
Reply To: Windows System Software Devs Interest List
Sent: Tuesday, January 29, 2008 8:49 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] How to add new interface and functionality to the existing device stack

Michal,

Except for the requirement of PnP loading the new driver after the
original (if this is a requirement), one can easily do this with a root
enumerated PnP driver, that uses IoRegisterPlugPlayNotification to know when
a new interface is available, then creates its own interface to use that
one.

–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply

“Michal Vodicka” wrote in message
> news:xxxxx@ntdev…
> I can miss something basic about PnP but can’t find a good way how to solve
> following problem. There is a hw device which has its own function driver
> supplied by 3rd party vendor. It exposes device interface standard way. Now
> there is a requirement to write a driver which uses the existing driver
> (i.e. doesn’t replace it) to implement its own functionality and exposes
> quite different interface. The requirement is that new driver is loaded
> automatically by PnP when the device is plugged in. PnP loads original
> function driver, it registers its interface and then new driver should be
> also loaded. Both interfaces should be available for its clients at once.
>
> I can imagine to install new driver as upper filter of existing one. But it
> is suboptimal because new driver would receive all traffic directed to the
> original driver and also, it doesn’t seem as correct design to me. The new
> driver is client of the original one, not the filter.
>
> Best regards,
>
> Michal Vodicka
> UPEK, Inc.
> [xxxxx@upek.com, http://www.upek.com]
>
>
>
>
> —
> 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
>

anton_bassov · January 29, 2008, 4:34pm

> I can imagine to install new driver as upper filter of existing one. But it is

suboptimal because new driver would receive all traffic directed to the original driver
and also, it doesn’t seem as correct design to me. The new driver is client of the original one, > not the filter.

To be honest, I don’t see any problem here. You can define your own interface and make your upper filter forward everything, apart from IRP_ MN_QUERY_INTERFACE, to the actual device, straight away. When IRP_ MN_QUERY_INTERFACE gets send to it, it should check InterfaceType GUID. If requested interface is the one that is implemented by your filter, then it should return function pointers, otherwise it should forward it down the stack. As a result, a client will be dealing with the actual device is all cases, apart from the ones when it requests services that are specific to your filter. What is the problem here???

Anton Bassov

OSR_Community_User · January 29, 2008, 4:46pm

One thing you could do is put a reference string on the new driver’s device interface (make it a GUID so that it’s unique). When you see a CREATE operation you can check the reference string and flag the file object if it’s for your interface. With that information your filter can easily decide which operations to send to the lower driver without touching and which are directed at it.

You still need to send the I/O to the lower driver, but you don’t need to check I/O control codes to decide which request goes where.

Another option would be to write a small KMDF bus driver that loads as a filter on the original device and enumerates a PDO for your driver. This would also let you start and stop (load and unload) your second driver without affecting the state of the original one. But it’s more code and complexity for a very similar effect.

-p

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Michal Vodicka
Sent: Tuesday, January 29, 2008 11:45 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] How to add new interface and functionality to the existing device stack

I can miss something basic about PnP but can’t find a good way how to solve following problem. There is a hw device which has its own function driver supplied by 3rd party vendor. It exposes device interface standard way. Now there is a requirement to write a driver which uses the existing driver (i.e. doesn’t replace it) to implement its own functionality and exposes quite different interface. The requirement is that new driver is loaded automatically by PnP when the device is plugged in. PnP loads original function driver, it registers its interface and then new driver should be also loaded. Both interfaces should be available for its clients at once.

I can imagine to install new driver as upper filter of existing one. But it is suboptimal because new driver would receive all traffic directed to the original driver and also, it doesn’t seem as correct design to me. The new driver is client of the original one, not the filter.

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

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

Michal_Vodicka-2 · January 29, 2008, 5:25pm

> ----------

From: xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com] on behalf of Doron Holan[SMTP:xxxxx@microsoft.com]
Reply To: Windows System Software Devs Interest List
Sent: Tuesday, January 29, 2008 9:42 PM
To: Windows System Software Devs Interest List
Subject: RE: Re:[ntdev] How to add new interface and functionality to the existing device stack

Is the requirement that your driver load on demand when the other device appears created by the fact that you do not want the new device interface to always be present? E.g. that it is only available when the 3rd party driver is present?

Exactly. It is because other software will wait for my new devices and they can’t work until real hardware is present.

If so, as don suggested, you can always be a root enumerated device and then selectively enable/disable your new device interface based on the presence of the 3rd party device stack.

Yes, I understand it. But it is ugly. As I wrote in reply to Don (my mails are delayed for some reason…), I don’t know how many 3rd party devices will be present. In fact, there can be more devices of different kind which I have to support. So if I understand it correctly, I’d have to install sufficient number of root enumerated devices and enable/disable interfaces as hw appears and disappears.

BTW, what do you say about virtual bus idea? Is it feasible for this purpose? Looks like an overkill to me but in principle it seems correct. Basically, I need to create one or more instances of virtual hardware (new interface) using real hw (3rd party or OS drivers).

OTOH, being a filter on top of the 3rd part device stack would be my initial stab at a solution. So what if you see all the traffic for the 3rd party device. IoSkip/IoCall is not going to add any noticeable overhead.

You’re right but it is even uglier I prefer clean and correct design. In addition, adding a filter, even pass-through can lead to unexpected problems with 3rd party drivers or software using them.

In other words, I hoped there is some supported solution for this kind of problem which I missed. It seems as there isn’t which is a bit strange because my requirements don’t seem so unusual.

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

Michal_Vodicka-2 · January 29, 2008, 6:03pm

> ----------

From: xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com] on behalf of Ray Trent[SMTP:xxxxx@synaptics.spamblock.com]
Reply To: Windows System Software Devs Interest List
Sent: Tuesday, January 29, 2008 10:04 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] How to add new interface and functionality to the existing device stack

(I don’t recommend this, but in case you’re curious: I think it’s
possible to have a user mode service that registers for interface
notification on the 3rd party driver’s interface, let WMI start that
service automagically when the interface appears, and have the service
demand start your driver… ugh… no, double ugh)

Nice idea No need for WMI, Setup API allows it, too. Devices could be disabled and enabled when original device appears

I don’t think something like this would be really necessary. I just hoped there is some PnP way which’d automagically do what I want. Register a driver as a client of some else driver.

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

Michal_Vodicka-2 · January 29, 2008, 6:47pm

> ----------

From: xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com] on behalf of xxxxx@hotmail.com[SMTP:xxxxx@hotmail.com]
Reply To: Windows System Software Devs Interest List
Sent: Tuesday, January 29, 2008 10:34 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] How to add new interface and functionality to the existing device stack

To be honest, I don’t see any problem here. You can define your own interface and make your upper filter forward everything, apart from IRP_ MN_QUERY_INTERFACE, to the actual device, straight away. When IRP_ MN_QUERY_INTERFACE gets send to it, it should check InterfaceType GUID. If requested interface is the one that is implemented by your filter, then it should return function pointers, otherwise it should forward it down the stack. As a result, a client will be dealing with the actual device is all cases, apart from the ones when it requests services that are specific to your filter. What is the problem here???

I guess the problem here is clients aren’t other kernel drivers but user mode apps. I’m speaking about IoRegisterDeviceInterface() and not about IRP_MN_QUERY_INTERFACE. Sorry if it wasn’t clear.

The filter solution clear. The problem I have with it is that it is kind of design hack. It’d work but it’d misuse filter concept as I see it. Client and filter are two distinct concept for me.

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

Michal_Vodicka-2 · January 29, 2008, 7:17pm

> ----------

From: xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com] on behalf of Peter Wieland[SMTP:xxxxx@windows.microsoft.com]
Reply To: Windows System Software Devs Interest List
Sent: Tuesday, January 29, 2008 10:45 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] How to add new interface and functionality to the existing device stack

One thing you could do is put a reference string on the new driver’s device interface (make it a GUID so that it’s unique). When you see a CREATE operation you can check the reference string and flag the file object if it’s for your interface. With that information your filter can easily decide which operations to send to the lower driver without touching and which are directed at it.

Thanks, I was just pondering it. Who handles reference strings? OS internally when receives create request for an interface which was registered with a reference string?

You still need to send the I/O to the lower driver, but you don’t need to check I/O control codes to decide which request goes where.

Another option would be to write a small KMDF bus driver that loads as a filter on the original device and enumerates a PDO for your driver. This would also let you start and stop (load and unload) your second driver without affecting the state of the original one. But it’s more code and complexity for a very similar effect.

But if we take into account there can be more devices driven by different drivers (both 3rd and OS), it can be viable solution. Bus driver could be installed as root enumerated device and register device notification for all supported hardware. When some appears, it’d create a virtual PDO for it and OS would load a function driver for this virtual device. The function driver would implement necessary functionality and expose requested interface. Is this idea correct?

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

Doron_Holan · January 29, 2008, 7:51pm

I still do not see a need for a bus driver. You can create and change the state of multiple instances of the same device interface guid in one driver. The caveat is that each instance must have its own unique reference string (you could probably use the 3rd party’s driver’s interfaces string (minus the \s) as your own reference string). You can differentiate which interface is being opened by inspecting the filename in your IRP_MJ_CREATE handler and comparing to the active instances you have enabled.

I think you are too quick to dismiss the filter idea though. It is a much cleaner solution and IMHO, not as hacky or error prone as you describe.

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Michal Vodicka
Sent: Tuesday, January 29, 2008 2:25 PM
To: Windows System Software Devs Interest List
Subject: RE: Re:[ntdev] How to add new interface and functionality to the existing device stack

From: xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com] on behalf of Doron Holan[SMTP:xxxxx@microsoft.com]
Reply To: Windows System Software Devs Interest List
Sent: Tuesday, January 29, 2008 9:42 PM
To: Windows System Software Devs Interest List
Subject: RE: Re:[ntdev] How to add new interface and functionality to the existing device stack

Is the requirement that your driver load on demand when the other device appears created by the fact that you do not want the new device interface to always be present? E.g. that it is only available when the 3rd party driver is present?

Exactly. It is because other software will wait for my new devices and they can’t work until real hardware is present.

If so, as don suggested, you can always be a root enumerated device and then selectively enable/disable your new device interface based on the presence of the 3rd party device stack.

Yes, I understand it. But it is ugly. As I wrote in reply to Don (my mails are delayed for some reason…), I don’t know how many 3rd party devices will be present. In fact, there can be more devices of different kind which I have to support. So if I understand it correctly, I’d have to install sufficient number of root enumerated devices and enable/disable interfaces as hw appears and disappears.

BTW, what do you say about virtual bus idea? Is it feasible for this purpose? Looks like an overkill to me but in principle it seems correct. Basically, I need to create one or more instances of virtual hardware (new interface) using real hw (3rd party or OS drivers).

OTOH, being a filter on top of the 3rd part device stack would be my initial stab at a solution. So what if you see all the traffic for the 3rd party device. IoSkip/IoCall is not going to add any noticeable overhead.

You’re right but it is even uglier I prefer clean and correct design. In addition, adding a filter, even pass-through can lead to unexpected problems with 3rd party drivers or software using them.

In other words, I hoped there is some supported solution for this kind of problem which I missed. It seems as there isn’t which is a bit strange because my requirements don’t seem so unusual.

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

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

Michal_Vodicka-2 · January 29, 2008, 9:34pm

> ----------

From: xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com] on behalf of Doron Holan[SMTP:xxxxx@microsoft.com]
Reply To: Windows System Software Devs Interest List
Sent: Wednesday, January 30, 2008 1:49 AM
To: Windows System Software Devs Interest List
Subject: RE: Re:[ntdev] How to add new interface and functionality to the existing device stack

I still do not see a need for a bus driver. You can create and change the state of multiple instances of the same device interface guid in one driver. The caveat is that each instance must have its own unique reference string (you could probably use the 3rd party’s driver’s interfaces string (minus the \s) as your own reference string). You can differentiate which interface is being opened by inspecting the filename in your IRP_MJ_CREATE handler and comparing to the active instances you have enabled.

Interesting idea. If I understand correctly, I’d have one device with multiple interfaces. I’d have to keep per-interface context some way (FsContext?) and simulate multiple devices internally. Is it really simpler than bus driver? I never wrote one.

I think you are too quick to dismiss the filter idea though. It is a much cleaner solution and IMHO, not as hacky or error prone as you describe.

I haven’t dismissed it, yet. I see it has some advantages. It is just my “sense of correctness” what doesn’t like it. And I always regretted when I didn’t hear it in the past… and vice versa

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

Doron_Holan · January 29, 2008, 10:53pm

Yes, you can establish a context in FsContext. You seem to be a bit uneasy about adding new drivers (at least that seems that way to me), so a bus driver would just create more devnodes and more INFs for you to deal with. Besides, you will still have an association problem to solve (how to map an instance of a 3rd party interface to which PDO you enumerate), I guess it can be 1:1. Each PDO would then be told which instance of the 3rd party stack to open. So now you still have context per instance of 3rd party interface, just not in the form of a FsContext.

You should experiment with the bus driver though. Writing one in KMDF is super easy. In your case I would start with the toaster dynambus sample.

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Michal Vodicka
Sent: Tuesday, January 29, 2008 6:34 PM
To: Windows System Software Devs Interest List
Subject: RE: Re:[ntdev] How to add new interface and functionality to the existing device stack

From: xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com] on behalf of Doron Holan[SMTP:xxxxx@microsoft.com]
Reply To: Windows System Software Devs Interest List
Sent: Wednesday, January 30, 2008 1:49 AM
To: Windows System Software Devs Interest List
Subject: RE: Re:[ntdev] How to add new interface and functionality to the existing device stack

I still do not see a need for a bus driver. You can create and change the state of multiple instances of the same device interface guid in one driver. The caveat is that each instance must have its own unique reference string (you could probably use the 3rd party’s driver’s interfaces string (minus the \s) as your own reference string). You can differentiate which interface is being opened by inspecting the filename in your IRP_MJ_CREATE handler and comparing to the active instances you have enabled.

Interesting idea. If I understand correctly, I’d have one device with multiple interfaces. I’d have to keep per-interface context some way (FsContext?) and simulate multiple devices internally. Is it really simpler than bus driver? I never wrote one.

I think you are too quick to dismiss the filter idea though. It is a much cleaner solution and IMHO, not as hacky or error prone as you describe.

I haven’t dismissed it, yet. I see it has some advantages. It is just my “sense of correctness” what doesn’t like it. And I always regretted when I didn’t hear it in the past… and vice versa

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

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

OSR_Community_User · January 30, 2008, 1:34am

The reference string gets tacked on to the target of the symbolic link for the device interface. So when someone opens up the sym link they get from SetupDi it points to \Device\MADEUP_PDO_NAME\foo which parses to the device \Device\MADEUP_PDO_NAME with a file name of \foo. Doron’s blog has some good articles about this (http://blogs.msdn.com/doronh/archive/2007/10/03/devices-and-namespaces.aspx and http://blogs.msdn.com/doronh/archive/2006/08/18/706717.aspx)

One thing to think about with the two driver in a stack solution is whether you’re okay with the other driver being the power policy owner for the stack, since there can only be one in a stack. Since you’re a “client” you probably are, in which case I think putting the two drivers in one stack is a perfectly elegant solution.

-p

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Michal Vodicka
Sent: Tuesday, January 29, 2008 4:17 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] How to add new interface and functionality to the existing device stack

From: xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com] on behalf of Peter Wieland[SMTP:xxxxx@windows.microsoft.com]
Reply To: Windows System Software Devs Interest List
Sent: Tuesday, January 29, 2008 10:45 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] How to add new interface and functionality to the existing device stack

One thing you could do is put a reference string on the new driver’s device interface (make it a GUID so that it’s unique). When you see a CREATE operation you can check the reference string and flag the file object if it’s for your interface. With that information your filter can easily decide which operations to send to the lower driver without touching and which are directed at it.

Thanks, I was just pondering it. Who handles reference strings? OS internally when receives create request for an interface which was registered with a reference string?

You still need to send the I/O to the lower driver, but you don’t need to check I/O control codes to decide which request goes where.

Another option would be to write a small KMDF bus driver that loads as a filter on the original device and enumerates a PDO for your driver. This would also let you start and stop (load and unload) your second driver without affecting the state of the original one. But it’s more code and complexity for a very similar effect.

But if we take into account there can be more devices driven by different drivers (both 3rd and OS), it can be viable solution. Bus driver could be installed as root enumerated device and register device notification for all supported hardware. When some appears, it’d create a virtual PDO for it and OS would load a function driver for this virtual device. The function driver would implement necessary functionality and expose requested interface. Is this idea correct?

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

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

Maxim_S_Shatskih · January 30, 2008, 6:37am

>which I missed. It seems as there isn’t which is a bit strange because my

requirements don’t seem so unusual.

Demand-loading a driver on other driver’s interface arrival is unusual.

If you will drop this requirement, then the single root-enumerated PDO
registered for device interface arrival notifications will suite.

–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

Michal_Vodicka-2 · January 30, 2008, 12:59pm

> ----------

From: xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com] on behalf of Doron Holan[SMTP:xxxxx@microsoft.com]
Reply To: Windows System Software Devs Interest List
Sent: Wednesday, January 30, 2008 4:50 AM
To: Windows System Software Devs Interest List
Subject: RE: Re:[ntdev] How to add new interface and functionality to the existing device stack

Yes, you can establish a context in FsContext. You seem to be a bit uneasy about adding new drivers (at least that seems that way to me), so a bus driver would just create more devnodes and more INFs for you to deal with. Besides, you will still have an association problem to solve (how to map an instance of a 3rd party interface to which PDO you enumerate), I guess it can be 1:1. Each PDO would then be told which instance of the 3rd party stack to open. So now you still have context per instance of 3rd party interface, just not in the form of a FsContext.

I thought it’d work following way. Bus driver would register PnP notifications for all supported 3rd party and OS interfaces. When a notification arrives, it’d open arrived device, create PDO and store all necessary info to the PDO device extension (context). When PDO is created, PnP would install and load function driver for it. It’d create FDO and register new interface. There would be private communication protocol between function and bus driver and device extensions would be used as contexts. I guess for any of supported 3rd party and OS interfaces there should be one function driver but it is OK and will have to be done anyway.

Maybe I don’t have right picture; feel free to correct me.

BTW, I forgot one important thing. The driver exporting new interface has to be written using UMDF. There are very good reasons for it. You know my opinion about frameworks without sources but it this case I don’t see other possibility. I guess it rules our filter solution. If I remember correctly, UMDF driver can’t be installed as a filter of kernel driver.

You should experiment with the bus driver though. Writing one in KMDF is super easy. In your case I would start with the toaster dynambus sample.

Yes, I will. Maybe I tend to see it as the best solution only because I don’t know enough about it

Thanks.

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

Michal_Vodicka-2 · January 30, 2008, 1:09pm

> ----------

From: xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com] on behalf of Peter Wieland[SMTP:xxxxx@windows.microsoft.com]
Reply To: Windows System Software Devs Interest List
Sent: Wednesday, January 30, 2008 7:33 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] How to add new interface and functionality to the existing device stack

The reference string gets tacked on to the target of the symbolic link for the device interface. So when someone opens up the sym link they get from SetupDi it points to \Device\MADEUP_PDO_NAME\foo which parses to the device \Device\MADEUP_PDO_NAME with a file name of \foo. Doron’s blog has some good articles about this (http://blogs.msdn.com/doronh/archive/2007/10/03/devices-and-namespaces.aspx and http://blogs.msdn.com/doronh/archive/2006/08/18/706717.aspx)

Thanks, it is exactly what I wanted to know. In other words, application enumerates device standard way using SetupDi and opens devices using CreateFile() without any additional work. Sounds good.

One thing to think about with the two driver in a stack solution is whether you’re okay with the other driver being the power policy owner for the stack, since there can only be one in a stack. Since you’re a “client” you probably are, in which case I think putting the two drivers in one stack is a perfectly elegant solution.

Yes. The original driver handles real hardware whereas new one implements something like virtual hw over existing one. But I don’t see it as one stack. Instead, there is original stack and new stack using original one.

Well, it seems I forgot to state one important thing which excludes filter solution. The new driver has to be UMDF (to make you happy and if I understand correctly, UMDF driver can’t be installed as kernel driver filter.

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

OSR_Community_User · January 30, 2008, 1:09pm

You remember incorrectly. A UMDF driver can sit on top of a kernel-mode driver. A kernel-mode driver cannot (today) live on top of a user-mode driver.

So your driver exposing the new interface can be a UMDF driver on top of a KMDF/WDM driver implementing the old interface.

-p

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Michal Vodicka
Sent: Wednesday, January 30, 2008 9:59 AM
To: Windows System Software Devs Interest List
Subject: RE: Re:[ntdev] How to add new interface and functionality to the existing device stack

From: xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com] on behalf of Doron Holan[SMTP:xxxxx@microsoft.com]
Reply To: Windows System Software Devs Interest List
Sent: Wednesday, January 30, 2008 4:50 AM
To: Windows System Software Devs Interest List
Subject: RE: Re:[ntdev] How to add new interface and functionality to the existing device stack

Yes, you can establish a context in FsContext. You seem to be a bit uneasy about adding new drivers (at least that seems that way to me), so a bus driver would just create more devnodes and more INFs for you to deal with. Besides, you will still have an association problem to solve (how to map an instance of a 3rd party interface to which PDO you enumerate), I guess it can be 1:1. Each PDO would then be told which instance of the 3rd party stack to open. So now you still have context per instance of 3rd party interface, just not in the form of a FsContext.

I thought it’d work following way. Bus driver would register PnP notifications for all supported 3rd party and OS interfaces. When a notification arrives, it’d open arrived device, create PDO and store all necessary info to the PDO device extension (context). When PDO is created, PnP would install and load function driver for it. It’d create FDO and register new interface. There would be private communication protocol between function and bus driver and device extensions would be used as contexts. I guess for any of supported 3rd party and OS interfaces there should be one function driver but it is OK and will have to be done anyway.

Maybe I don’t have right picture; feel free to correct me.

BTW, I forgot one important thing. The driver exporting new interface has to be written using UMDF. There are very good reasons for it. You know my opinion about frameworks without sources but it this case I don’t see other possibility. I guess it rules our filter solution. If I remember correctly, UMDF driver can’t be installed as a filter of kernel driver.

You should experiment with the bus driver though. Writing one in KMDF is super easy. In your case I would start with the toaster dynambus sample.

Yes, I will. Maybe I tend to see it as the best solution only because I don’t know enough about it

Thanks.

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

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

Michal_Vodicka-2 · January 30, 2008, 2:20pm

> ----------

From: xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com] on behalf of Peter Wieland[SMTP:xxxxx@windows.microsoft.com]
Reply To: Windows System Software Devs Interest List
Sent: Wednesday, January 30, 2008 7:09 PM
To: Windows System Software Devs Interest List
Subject: RE: Re:[ntdev] How to add new interface and functionality to the existing device stack

You remember incorrectly. A UMDF driver can sit on top of a kernel-mode driver. A kernel-mode driver cannot (today) live on top of a user-mode driver.

Ah OK, it was opposite case. Thanks.

So your driver exposing the new interface can be a UMDF driver on top of a KMDF/WDM driver implementing the old interface.

Fine, I will reconsider this possibility. There can be a performance issue for the old interface but it shouldn’t matter in our case.

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]