BubbaGump
Wed Oct 18 14:34:55 CDT 2006
That makes sense.
The terminology used in the device stack hierarchy confused me at one
point. I used to think the "functional device object" was always the
one provided by an outside driver writer until I realized that the
class drivers already provide the FDO so that a driver writer is left
to hook in a PDO from below (at least for storage, assuming all
outside storage drivers aren't just miniports).
On Wed, 18 Oct 2006 10:44:26 -0700, "Peter Wieland [MSFT]"
<peterwie@online.microsoft.com> wrote:
>The PPO does one other thing - it manages idle detection for the device.
>
>In storage i made the PDO the PPO for several reasons:
>
>1) Storage PDOs are RAW capable, so they will get started even if there's no
>function driver installed. By making the PDO the PPO we can do idle
>detection and Sx -> Dx mapping for raw storage devices. Without this
>powering down a system with a raw storage device would be much more
>complicated.
>
>2) In order to manage idle detection you need to keep track of what I/O is
>active. the storage port driver already does this as part of the interface
>with the class drivers, so it made the most logical sense for the port
>driver to manage all of the power transitions.
>
>Other stacks are free to make other decisions. For example the USB stack
>doesn't allow RAW access to its PDOs, so it can assume that a device which
>was started has a PPO loaded on it.