I assume he meant as in a scsi bus where the pdos forward IO operations
to the bus driver FDO - a standard model for a serial bus like scsi or
usb. But this indeed has little to do with PnP.
PnP and power state changes are issues that he is going to have to deal
with. Is it OK for the fabric FDO to allow itself to be stopped? How are
power state changes correctly managed?
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Arlie Davis
Sent: Thursday, January 05, 2006 2:38 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Bus driver FDO in different PnP hiearchy than
children PDO’s
Perhaps OP means “attached” in an informal sense, the sense that the
device
extension for the PDO contains a pointer to the bus FDO or the device
extension of the bus FDO, not that it is attached in the formal PNP
device
layering sense.
If it IS attached, then there would be lots of problems, among them:
device
removal ordering constraints (can’t detach a “middle” device object),
bizarre PNP IRP handling, power IRP handling, etc.
– arlie
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Bill McKenzie
Sent: Thursday, January 05, 2006 2:11 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Bus driver FDO in different PnP hiearchy than
children
PDO’s
Reading this some more I am confused about which driver is a fabric
driver
and which isn’t, I hope my initial assesment was correct.
One important note about bus drivers here: PDOs are not usually
attached to
anything. I suppose they could attach themselves to other stacks, but
this
is definitely not typical. FDOs are definitely attached to PDOs and
they
reside in the same driver stack. However, PDOs are generally the bottom
of
a given driver stack and are not attached to anything. They are managed
by
some parent FDO somewhere, but that FDO is in a different and distinct
driver stack. All the FDO is required to do is manage the creation,
initialization, and destruction of the PDOs, but the IRPs the PDO
receives
do not reach the parent FDO and vice versa.
Bill M.
“Bill McKenzie” wrote in message
news:xxxxx@ntdev…
It sounds to me, at first reading anyway, that you actually want
filter drivers sitting in the fabric drivers stack and you want
communication with those filter drivers to your “bus” driver or bus
driver’s
child devices somehow.
Having a bus driver create child devices that attach to other
stacks
seems like it might be problematic wrt power. Only someone who has
done
this, AND tested power scenarios thoroughly, or someone with source
access
would know for sure. The parent FDO of a bus driver is not allowed to
go to
a less powered state until all of its child device stacks have gone to
the
same or even less powered states. Conversely, a bus’s child device
cannot
go to a more powered state until the parent FDO has powered up to the
same
or even more powered state. Normally, the power manager will handle
this
and for example will not send a power IRP to the FDO for a less powered
state until all of the PDOs have already been powered down. In your
case
though, I am not sure this will be handled properly. You can’t block in
a
power IRP dispatch handler, so if the power manager did not handle this
situation properly it would be hard to make this work. All of that
said, I
suspect the power manager would do the right thing here. Perhaps
someone
from Microsoft could comment.
Interesting problem.
Bill M.
“Jan Bottorff” wrote in message
news:xxxxx@ntdev…
I’m working on a product (I’m a consultant) using
unified
fabric I/O devices (InfiniBand). The fabric drivers come with a virtual
bus
driver that creates devices that are discovered on the fabric. My
product
also has a virtual bus driver that creates devices that are accessed
across
the fabric. I’m trying to understand if my virtual bus needs to be a PnP
child of the fabric virtual bus, or if it can stand side by side with
the
fabric virtual bus. At the bottom is the fabric I/O device, which is a
child
of the PCI bus. There is a call based interface to the fabric driver for
most requests, and most IRP’s just get passed down (except
QueryInterface
for the call interface).
Now the part that’s confusing to me. The fabric bus
driver
is root enumerated, and when it creates a child PDO it attaches it to
the
actual fabric device, NOT to its own virtual bus FDO. I tend to think of
bus
drivers as having a FDO, attached to some PDO, and new PDO’s the bus
creates
are attached to the bus driver FDO. This creates a PnP hierarchy that
funnels all bus children through the bus FDO. The first question: what
are
the implications if a bus driver to creates PDO’s in some other PnP
hierarchy?
So now the second problem. Without modifying the fabric
bus
driver to create a PDO for my bus driver, the only alternative is for my
virtual bus driver to be root enumerated. Devices on my virtual bus need
to
be in the PnP hierarchy of the actual fabric device and underlying PCI
bus,
so things like QueryInterface’s to get the DMA adapter work correctly.
It’s
occurred to me that I could make my bus driver do the same thing as the
fabric bus driver, attach child PDO’s to the fabric device directly. The
end
result would be a bunch of virtual device PDO’s all having the fabric
device
as a parent, with two bus driver FDO’s living off to the side. I’m quite
confused about the PnP and power management implications of this device
hierarchy, although the bus drivers do get to process any IRP’s passing
through the PDO, so should be able to “do the right thing”.
A little complication is one of the virtual devices on
my
virtual bus can be the boot storage adapter. I’ve read here on NTDEV
that a
device MUST be in the PnP hierarchy of actual hardware to boot from it.
The
three alternatives I have are:
1) both my virtual bus and the fabric virtual bus
are
root enumerated (set as boot drivers in a very early start group) and
create
a storage device that is in the PnP hierarchy of real hardware, even
though
the virtual bus FDO’s aren’t
2) my virtual bus becomes a child of the fabric
virtual bus, making my virtual bus parent be the fabric device
3) I will have to change the fabric drivers to
arrange
the fabric driver to not be root enumerated, but be a filter device on
the
fabric hardware device, creating a child PDO which my virtual bus
attaches
to, eliminating all root enumerated devices and making the PnP hierarchy
more straightforward
Changing the fabric drivers would be hard, but not
impossible, so arranging my virtual bus to work correctly with no
changes to
the fabric virtual bus drivers would be strongly preferable. The bottom
line
is: it has to work (and boot from a virtual fabric device).
Any bus driver wizards out there?
- Jan
—
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
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@stratus.com
To unsubscribe send a blank email to xxxxx@lists.osr.com