Pnp Compared to NonPnp

Are their any advantages to having a nonpnp driver compared to a pnp driver? Like for example non pnp you need wdfcoinstaller and a inf file. A pnp you don’t need any of those, I would just like to know if nonpnp is worth it more than pnp.

If your device is a pnp device you need a pnp driver for it. If your device
is not a pnp device you can still use a pnp driver for it as a software
enumerated (virtual) pnp device. Off hand, outside of things like
filesystems or system utilities or malware, I cannot think of any reason to
use a non-pnp device.

Mark Roddy

On Sun, Jun 28, 2015 at 2:16 PM, wrote:

> Are their any advantages to having a nonpnp driver compared to a pnp
> driver? Like for example non pnp you need wdfcoinstaller and a inf file. A
> pnp you don’t need any of those, I would just like to know if nonpnp is
> worth it more than pnp.
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>
> 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
>

Ya we are talking about software in general here, no hardware like a usb or a keyboard. So you say pnp and non pnp are equivalent, just non pnp needs the inf and dll.

For a software only driver that is intended to always start when the system
starts and that is using WDF I happen to think that a root enumerated
software only pnp driver is easier to install and implement than a non-pnp
WDF driver. See the “KMDF Echo Sample” in the win8.1 WDK. I honestly can’t
remember the last time I worked on a non-pnp WDF driver. If you are looking
for the absolute simplest approach a legacy software only driver (i.e. not
WDF not WDM not PnP) is still possible.

Mark Roddy

On Sun, Jun 28, 2015 at 4:28 PM, wrote:

> Ya we are talking about software in general here, no hardware like a usb
> or a keyboard. So you say pnp and non pnp are equivalent, just non pnp
> needs the inf and dll.
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>
> 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
>

I agree with Mr. Roddy wholeheartedly.

In general, software-only drivers that exist outside the world of PnP or power management are referred to as Kernel Services. These are almost always implemented as NT V4 style kernel node drivers. They do things like handle Registry or Process creation callbacks. They are managed entirely with the Service Control Manager. These drivers are WDM drivers, without PnP or Power. They create their Device Object within DriverEntry. These drivers are very well know… However they can not use WDF.

I also agree with Mr. Roddy’s assessment that if you *really* want to write a software-only driver using WDF, it’s probably best to just write a root-enumerated PnP driver. You’ll have it working in minutes, and the model will be familiar to anyone who picks it up to maintain it later.

Peter
OSR
@OSRDrivers

The statement that non-pnp drivers (kernel services) can’t use WDF is
incorrect. WDF gives non-pnp drivers all the WDF user to driver support,
queues, cancel safe, etc. Writing such a driver as a root-enumerated
driver is not the only way and not always to best way to go. A good
example is a driver that is monitoring registry access. There is no
reason for this driver to be loaded at boot time if it isn’t needed
until the user side needs the services of the driver. The user
application has the normal service control of this driver.

Bill Wandel

On 2015-06-29 09:23, xxxxx@osr.com wrote:

I agree with Mr. Roddy wholeheartedly.

In general, software-only drivers that exist outside the world of PnP or power management are referred to as Kernel Services. These are almost always implemented as NT V4 style kernel node drivers. They do things like handle Registry or Process creation callbacks. They are managed entirely with the Service Control Manager. These drivers are WDM drivers, without PnP or Power. They create their Device Object within DriverEntry. These drivers are very well know… However they can not use WDF.

I also agree with Mr. Roddy’s assessment that if you *really* want to write a software-only driver using WDF, it’s probably best to just write a root-enumerated PnP driver. You’ll have it working in minutes, and the model will be familiar to anyone who picks it up to maintain it later.

Peter
OSR
@OSRDrivers


NTDEV is sponsored by OSR

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev [1]

OSR is HIRING!! See http://www.osr.com/careers [2]

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars [3]

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer [4]

Links:

[1] http://www.osronline.com/showlists.cfm?list=ntdev
[2] http://www.osr.com/careers
[3] http://www.osr.com/seminars
[4] http://www.osronline.com/page.cfm?name=ListServer

That statement is absolutely true. Thank you, Mr. Wandel

My response could have been worded more clearly. I was insufficiently clear that I was referring to “NT V4 style kernel mode drivers” as the types of driver that “can not use WDF.”

Well, that’s a matter of opinion, of course, not architecture.

I would agree that writing a root-enumerated WDF PnP driver for software-only tasks is not always the “best way to go.” Unless there’s a lot of interaction with other I/O Targets, I would argue that writing an NT V4 style Kernel Mode Driver is the best approach.

I’ve personally never seen a non-PnP WDF driver “in the wild”… and I would argue that non-PnP WDF drivers provide very little value relative to its level rarity.

In MY opinion, the choice is between an NT V4 kernel-mode driver as a Kernel Service or root-enumerated WDF PnP software-only driver. In my own practice, I don’t consider non-PnP WDF drivers to even be an option.

(As an aside, I would argue that you most ESPECIALLY want a driver that implements Cm or Ps callbacks to be loaded at boot time, to avoid missing any operations.)

Peter
OSR
@OSRDrivers

What I meant was, a pnp and non pnp driver. Both do the same things, both are only run once and than close, When the user decides to open the exe, that is the only time either of the drivers run. So, does it matter, pnp or non pnp at speed and efficiency.

xxxxx@gmail.com wrote:

What I meant was, a pnp and non pnp driver. Both do the same things, both are only run once and than close, When the user decides to open the exe, that is the only time either of the drivers run. So, does it matter, pnp or non pnp at speed and efficiency.

The choice is not based on speed and efficiency. PnP vs non-PnP affects
how the drivers are installed and loaded. Once loaded, the execution is
identical.

A PnP driver is installed using an INF, and is always loaded in response
to the arrival of some device. That can be a real device or a virtual
device, but the process starts with the creation of a new device.

A non-PnP driver is installed, loaded and unloaded using the Service
Manager. In many cases, that’s a more sensible approach, but it depends
on your philosophy.


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