PNP transitions and serialization

NTDEV
1

Are drivers guaranteed that PNP IRPs sent to them are serialized? The
toaster bus DDK sample omits synchronization in many of the paths that
process PNP IRPs, even when accessing data that is shared between the bus
FDO and the child PDOs.

If they are serialized, what is the scope of the serialization? Serialized
with respect to each device object? (i.e. at most one request active on a
given device object) Or serialized with respect to entire OS?

If they are not serialized, what is the best way to serialize these state
transitions?

Thanks for any information.

– arlie

2

Pnp state changing irps are serialized, not all pnp irps fall into that category. Pnp irps are serialized based on the device tree really. If you have 2 different device trees with different roots, there is nothing to stop the pnp manage from changing the state of both tres at the same time. In today’s implementation , it is serialized across the entire OS (*). For a PDO and FDO pair, the PDO’s state is dependent on the FDO’s state. That means that only one state transition will be pending between an FDO and PDO pair (let’s say processing query remove). That does not apply to sibling PDOs, one PDO could be potentially moving into one state (query stop) and another PDO could be starting at the same time.

That help?

D

(*) start and QDR/BusRelations have been turned into async operations in Vista so that more then one device tree can be started at a time.

From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Arlie Davis
Sent: Wednesday, December 14, 2005 10:49 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] PNP transitions and serialization

Are drivers guaranteed that PNP IRPs sent to them are serialized?? The toaster bus DDK sample omits synchronization in many of the paths that process PNP IRPs, even when accessing data that is shared between the bus FDO and the child PDOs.
?
If they are serialized, what is the scope of the serialization?? Serialized with respect to each device object?? (i.e. at most one request active on a given device object)? Or serialized with respect to entire OS?
?
If they are not serialized, what is the best way to serialize these state transitions?
?
Thanks for any information.
?
– arlie
?

Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

3

state changing requests are serialized at least at the device level by
the PNP manager. Remember though that not all PNP requests are state
changing (QUERY_INTERFACE, QUERY_CAPABILITES, ones that request data
from the lower device) and since these can be initiated by an upper
driver, they are not synchronized with the state-changing operations.

-p

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Arlie Davis
Sent: Wednesday, December 14, 2005 10:49 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] PNP transitions and serialization

Are drivers guaranteed that PNP IRPs sent to them are serialized? The
toaster bus DDK sample omits synchronization in many of the paths that
process PNP IRPs, even when accessing data that is shared between the
bus FDO and the child PDOs.

If they are serialized, what is the scope of the serialization?
Serialized with respect to each device object? (i.e. at most one
request active on a given device object) Or serialized with respect to
entire OS?

If they are not serialized, what is the best way to serialize these
state transitions?

Thanks for any information.

– arlie

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

4

That helps some. However, please clarify a few things. Let’s say that an
FDO bus driver creates 2 PDOs, “A” and “B”. Which of the following sets of
devices can receive state-changing PNP requests concurrently, and which
cannot?

  1. Bus and PDO A
  2. PDO A and PDO B
  3. Bus, PDO A, PDO B

By “PDO and FDO pair”, do you mean the device objects in a single device
object stack? i.e. an FDO that is attached to a PDO? Or do you mean the
parent/child relationship between the FDO bus driver and PDO child?

Thanks much.

– arlie

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
Sent: Wednesday, December 14, 2005 2:04 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] PNP transitions and serialization

Pnp state changing irps are serialized, not all pnp irps fall into that
category. Pnp irps are serialized based on the device tree really. If you
have 2 different device trees with different roots, there is nothing to stop
the pnp manage from changing the state of both tres at the same time. In
today’s implementation , it is serialized across the entire OS (*). For a
PDO and FDO pair, the PDO’s state is dependent on the FDO’s state. That
means that only one state transition will be pending between an FDO and PDO
pair (let’s say processing query remove). That does not apply to sibling
PDOs, one PDO could be potentially moving into one state (query stop) and
another PDO could be starting at the same time.

That help?

D

(*) start and QDR/BusRelations have been turned into async operations in
Vista so that more then one device tree can be started at a time.

5

Concurrent: case 2
Serialized: cases 1 & 3

Think of the parent/child relationship this way. A child cannot be
running if the parent is not running. That means for a query stop/query
remove, the entire tree has to be locked and the tree is queried from
the children up to the root. Same for remove, the pnp manager changes
state from the children up to the root. This type of design would not
allow for a concurrent state change in both the parent and child at the
same time.

Now one would assume that the query remove canceled is sent from the
root and then downward to the children, but that is not the case. This
is a bug in the pnp manager on all currently shipping OS’s. The cancel
q.r. is sent from the children up to the root. This means that if you
enforce the rule during query remove, that a child cannot be in the
running/powered up state until the parent is in the running/powered up
state, you will deadlock b/c the child will get the canceled q.r. before
the parent, blocking the state change until the parent also moves into
the working state. What this boils down to is that you cannot treat
query remove w/in your own stack as an implicit power down state change,
q.r. becomes a notification to your driver that you can fail, but that’s
it.

By “PDO & FDO pair”, I meant the parent/child relation ship and not the
possible FDO attached to the PDO.

D

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Arlie Davis
Sent: Wednesday, December 14, 2005 11:27 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] PNP transitions and serialization

That helps some. However, please clarify a few things. Let’s say that
an
FDO bus driver creates 2 PDOs, “A” and “B”. Which of the following sets
of
devices can receive state-changing PNP requests concurrently, and which
cannot?

  1. Bus and PDO A
  2. PDO A and PDO B
  3. Bus, PDO A, PDO B

By “PDO and FDO pair”, do you mean the device objects in a single device
object stack? i.e. an FDO that is attached to a PDO? Or do you mean
the
parent/child relationship between the FDO bus driver and PDO child?

Thanks much.

– arlie

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
Sent: Wednesday, December 14, 2005 2:04 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] PNP transitions and serialization

Pnp state changing irps are serialized, not all pnp irps fall into that
category. Pnp irps are serialized based on the device tree really. If
you
have 2 different device trees with different roots, there is nothing to
stop
the pnp manage from changing the state of both tres at the same time.
In
today’s implementation , it is serialized across the entire OS (*). For
a
PDO and FDO pair, the PDO’s state is dependent on the FDO’s state. That
means that only one state transition will be pending between an FDO and
PDO
pair (let’s say processing query remove). That does not apply to
sibling
PDOs, one PDO could be potentially moving into one state (query stop)
and
another PDO could be starting at the same time.

That help?

D

(*) start and QDR/BusRelations have been turned into async operations in
Vista so that more then one device tree can be started at a time.

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

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

6

Thank you, Doron. Such detailed and quick responses are much appreciated.

– arlie

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
Sent: Wednesday, December 14, 2005 2:53 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] PNP transitions and serialization

Concurrent: case 2
Serialized: cases 1 & 3

Think of the parent/child relationship this way. A child cannot be running
if the parent is not running. That means for a query stop/query remove, the
entire tree has to be locked and the tree is queried from
the children up to the root. Same for remove, the pnp manager changes
state from the children up to the root. This type of design would not allow
for a concurrent state change in both the parent and child at the same time.

Now one would assume that the query remove canceled is sent from the root
and then downward to the children, but that is not the case. This is a bug
in the pnp manager on all currently shipping OS’s. The cancel q.r. is sent
from the children up to the root. This means that if you enforce the rule
during query remove, that a child cannot be in the running/powered up state
until the parent is in the running/powered up state, you will deadlock b/c
the child will get the canceled q.r. before the parent, blocking the state
change until the parent also moves into the working state. What this boils
down to is that you cannot treat query remove w/in your own stack as an
implicit power down state change, q.r. becomes a notification to your driver
that you can fail, but that’s it.

By “PDO & FDO pair”, I meant the parent/child relation ship and not the
possible FDO attached to the PDO.

D

7

— Doron Holan wrote:

> If you have 2 different device trees with different
roots,
> there is nothing to stop the pnp manage from
> changing the state of both tres at the same time.

Hmmm, aren’t all pnp devs rooted at HTREE\ROOT\0 or
so? Do you mean os would simultaneously walk different
branches of the entire tree W/O holding the Device
Tree lock first?

Thanks,
Calvin Guan (Windows DDK MVP)
NetXtreme Longhorn Miniport Prime
Broadcom Corp. www.broadcom.com

__________________________________________________________
Find your next car at http://autos.yahoo.ca

8

Yes, eventually they all have the same root, but if you want to operate
on 2 distinct subtrees underneath the root, there is no inherit
relationship.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Calvin Guan
Sent: Wednesday, December 14, 2005 12:41 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] PNP transitions and serialization

— Doron Holan wrote:

> If you have 2 different device trees with different
roots,
> there is nothing to stop the pnp manage from
> changing the state of both tres at the same time.

Hmmm, aren’t all pnp devs rooted at HTREE\ROOT\0 or
so? Do you mean os would simultaneously walk different
branches of the entire tree W/O holding the Device
Tree lock first?

Thanks,
Calvin Guan (Windows DDK MVP)
NetXtreme Longhorn Miniport Prime
Broadcom Corp. www.broadcom.com

__________________________________________________________
Find your next car at http://autos.yahoo.ca

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

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