Static device object in PnP driver

Hi all,

can anyone tell me if the following architecture conforms to WHQL rules,
i.e. if it is certifiable by WHQL?

In a WDM PnP function driver (for a FireWire device) I plan to use a
global static device object. The static device object will be created
when the first FDO is created and will be deleted when the last FDO is
gone (and the last handle for it has been closed).
The static device object has a fixed name and a fixed symbolic link
created by means of IoCreateSymbolicLink. The static device object is
used to expose a driver API. The API calls have to be independent of the
presence of devices on the bus.

Udo Eberhardt
Thesycon GmbH

Just my two cents, I really don’t know what WHQL allows people to do.
However, this architecture is perfectly legal to me and I’d be surprised if
anyone complains about it.

Just a suggestion, if I may. I’d use a device interface instead of a
symbolic link. I like them better since they use guids.

Am I allowed another suggestion? :slight_smile: Why don’t you just implement this API
through any one of your FDOs? You could register and enable the same device
interface for all of them so the user would simply have to find one of your
devices and use it directly. That would eliminate the need for an extra
device object and also clear all doubts about whql certification :slight_smile:

Mat

-----Original Message-----
From: Udo Eberhardt [mailto:xxxxx@thesycon.de]
Sent: Friday, June 20, 2003 5:49 AM
To: NT Developers Interest List
Subject: [ntdev] Static device object in PnP driver

Hi all,

can anyone tell me if the following architecture conforms to WHQL rules,
i.e. if it is certifiable by WHQL?

In a WDM PnP function driver (for a FireWire device) I plan to use a
global static device object. The static device object will be created
when the first FDO is created and will be deleted when the last FDO is
gone (and the last handle for it has been closed).
The static device object has a fixed name and a fixed symbolic link
created by means of IoCreateSymbolicLink. The static device object is
used to expose a driver API. The API calls have to be independent of the
presence of devices on the bus.

Udo Eberhardt
Thesycon GmbH


You are currently subscribed to ntdev as: xxxxx@guillemot.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

Mathieu Routhier wrote:

Just a suggestion, if I may. I’d use a device interface instead of a
symbolic link. I like them better since they use guids.

A device interface requires a PDO and is therefore not usable with a
static device object.

Am I allowed another suggestion? :slight_smile: Why don’t you just implement this API
through any one of your FDOs? You could register and enable the same device
interface for all of them so the user would simply have to find one of your
devices and use it directly. That would eliminate the need for an extra
device object and also clear all doubts about whql certification :slight_smile:

The likely reason he needs a static device object is that he needs to
simultaneously control a number of FiDOs. He did say, after all, that
his API needed to be independent of the presence of devices.


Walter Oney, Consulting and Training
Basic and Advanced Driver Programming Seminars
Check out our schedule at http://www.oneysoft.com

Ok, I see, I see. But if the static device object is created when the first
FDO is created and destroyed when the last FDO goes away, this is not
independent of the presence of devices.

What would be the right way do this? Change the driver service type to
“system start” instead of “on demand”, and call IoCreateDevice() in
DriverEntry()?

Mat

-----Original Message-----
From: Walter Oney [mailto:xxxxx@oneysoft.com]
Sent: Friday, June 20, 2003 9:34 AM
To: NT Developers Interest List
Subject: [ntdev] Re: Static device object in PnP driver

Mathieu Routhier wrote:

Just a suggestion, if I may. I’d use a device interface instead of a
symbolic link. I like them better since they use guids.

A device interface requires a PDO and is therefore not usable with a
static device object.

Am I allowed another suggestion? :slight_smile: Why don’t you just implement this API
through any one of your FDOs? You could register and enable the same
device
interface for all of them so the user would simply have to find one of
your
devices and use it directly. That would eliminate the need for an extra
device object and also clear all doubts about whql certification :slight_smile:

The likely reason he needs a static device object is that he needs to
simultaneously control a number of FiDOs. He did say, after all, that
his API needed to be independent of the presence of devices.


Walter Oney, Consulting and Training
Basic and Advanced Driver Programming Seminars
Check out our schedule at http://www.oneysoft.com


You are currently subscribed to ntdev as: xxxxx@guillemot.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

Mathieu Routhier wrote:

What would be the right way do this? Change the driver service type to
“system start” instead of “on demand”, and call IoCreateDevice() in
DriverEntry()?

There’s really nothing wrong with what he’s trying to do. The only way
to know whether WHQL will be a problem is to run the tests.


Walter Oney, Consulting and Training
Basic and Advanced Driver Programming Seminars
Check out our schedule at http://www.oneysoft.com

Thanks for your comments.
Currently, the driver uses the design which Mat suggested: A device
interface is registered for each FDO. Because the API calls do not have
device context, it does not matter which device instance is opened by
the app. It always opens instance zero. The problem occurs if the user
disconnects one of the devices from the bus and this removes the FDO
instance which has been opened by the app. How should the driver handle
this situation? I think, there are two choices:
(a) Disable the FILE_OBJECT(s), which in fact disables the apps
handle(s). The app has to close all handles, to reenumerate device
interfaces and to reopen handles. Due to the apps design, this is not
easy to implement.
(b) Keep the FILE_OBJECT(s) and thus the API intact. IOCTLs can still
work, even if submitted on the removed device. However, this will hold
up the PNP REMOVE IRP. So the FDO will not be deleted. Looks not so
clean for me…

Mathieu Routhier wrote:

Ok, I see, I see. But if the static device object is created when the first
FDO is created and destroyed when the last FDO goes away, this is not
independent of the presence of devices.

The resulting behavior is: The driver API is available as long as at
least one device is connected. This is exactly what we need for the project.
I plan to delete the static DO in order to allow the driver to be
unloaded if its last device is disconnected from the PC.

What would be the right way do this? Change the driver service type to
“system start” instead of “on demand”, and call IoCreateDevice() in
DriverEntry()?

I’m not sure if this conforms to WDM rules for hot PnP devices (1394).

Udo Eberhardt
Thesycon GmbH