For the function DriverEntry() there is the opposite callback
DriverUnload(). This is symmetrical (and easy to remember/understand).

For IRP_MN_START_DEVICE there is the opposite IRP_MN_STOP_DEVICE.
This is symmetrical (and easy to remember/understand).


But for the function AddDevice() there is no corresponding (i.e.
symmetrical) RemoveDevice(). Instead, there is a minor IRP_MJ_PNP
hanlder: IRP_MN_REMOVE_DEVICE.

There must be a GOOD reason for this exception/asymmetry, right?

If so, what is it?

Thanks,
Don (who tries to understand a little deeper)

Re: Why this asymmetry in driver init/uninit API? by Don

Don
Thu Feb 07 14:39:18 CST 2008

Don,

The reason is that AddDevice needs to create a DEVICE_OBJECT while
IRP_MN_XXX is sent to the DEVICE_OBJECT created by AddDevice. Also, note
that IRP_MN_REMOVE_DEVICE is one of several calls for remove. The driver
can be queried on whether a remove is ok, and the driver can be surprise
removed due to an unplug type event.

One can argue there is a better model, in fact Microsoft recognized
the problems and created KMDF in part because of all the problems with the
PnP model. But, the model can be understood by the context it was created
in over 11 years ago.


--
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



<0dbell@gmail.com> wrote in message
news:ce529360-fa55-4b8c-b168-4f7d5ac11b1f@f10g2000hsf.googlegroups.com...
> For the function DriverEntry() there is the opposite callback
> DriverUnload(). This is symmetrical (and easy to remember/understand).
>
> For IRP_MN_START_DEVICE there is the opposite IRP_MN_STOP_DEVICE.
> This is symmetrical (and easy to remember/understand).
>
>
> But for the function AddDevice() there is no corresponding (i.e.
> symmetrical) RemoveDevice(). Instead, there is a minor IRP_MJ_PNP
> hanlder: IRP_MN_REMOVE_DEVICE.
>
> There must be a GOOD reason for this exception/asymmetry, right?
>
> If so, what is it?
>
> Thanks,
> Don (who tries to understand a little deeper)



Re: Why this asymmetry in driver init/uninit API? by Peter

Peter
Thu Feb 07 16:47:41 CST 2008

The asymmetry is there because there's no device object to receive an
IRP_MN_ADD_DEVICE IRP. AddDevice() is a driver level call and is made
before the driver has created a device or attached it to the stack.

Once a device is created and attached to the stack all subsequent PNP
operations come as IRPs.

-p

--
This posting is provided "AS IS" with no warranties, and confers no rights.


<0dbell@gmail.com> wrote in message
news:ce529360-fa55-4b8c-b168-4f7d5ac11b1f@f10g2000hsf.googlegroups.com...
> For the function DriverEntry() there is the opposite callback
> DriverUnload(). This is symmetrical (and easy to remember/understand).
>
> For IRP_MN_START_DEVICE there is the opposite IRP_MN_STOP_DEVICE.
> This is symmetrical (and easy to remember/understand).
>
>
> But for the function AddDevice() there is no corresponding (i.e.
> symmetrical) RemoveDevice(). Instead, there is a minor IRP_MJ_PNP
> hanlder: IRP_MN_REMOVE_DEVICE.
>
> There must be a GOOD reason for this exception/asymmetry, right?
>
> If so, what is it?
>
> Thanks,
> Don (who tries to understand a little deeper)


Re: Why this asymmetry in driver init/uninit API? by Maxim

Maxim
Sat Feb 09 09:11:31 CST 2008

> But for the function AddDevice() there is no corresponding (i.e.
> symmetrical) RemoveDevice(). Instead, there is a minor IRP_MJ_PNP
> hanlder: IRP_MN_REMOVE_DEVICE.
>
> There must be a GOOD reason for this exception/asymmetry, right?

AddDevice is called when there is no device object yet, while removal (and all
other operations) are called on existing device object.

This is the same assymetry as in C++ between constructor (called for
just-memory which is not an object yet) and destructor (called on existing
object).

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