TechTalkz.com Logo Ask the Experts!

Go Back   TechTalkz.com Technology & Computer Troubleshooting Forums > Tech Support Archives > Microsoft > Microsoft Device Drivers

Difference in PDO and FDO.

Microsoft Device Drivers

 
 
Thread Tools Display Modes
Unread 02-12-2007, 12:02 AM   #1
Ali
Guest
 
Posts: n/a
Difference in PDO and FDO.


PDO:
Represents the actual device which operates directly on the
underlying specific device. Like if we talk about PDO for USB (Assume 2
USBs on system) device or COM port (Assume 2 COMs on system) then it
means that for USB there is another PDO which is a HUB controller PDO
and for HUB controller PDO there is a Main bus PDO and that's it.
This is the PDO which corresponds to COM port PDOs as well. (For
parallel port there is just an single PDO which directly talks to main
bus PDO or it can be possible that it is directly talking to port,
don't know!)

And putting them together makes a device class like for USB it is USB
class having objects from HUB to Main bus PDOs.

FDO:
These are the function drivers that makes use of PDOs and they can
be more then one at any given time, say a Bulk FDO, Direct I\O FDO and
so on and so forth.

Filters:
Ah, making life easier just hanging on top of the stack to process
the interested IRPs ( happenings;-) ) and let the every other stranger
IRP pass through them down to the stack.


Lets hear from peers!
ali

 
Unread 02-12-2007, 12:02 AM   #2
Don Burn
Guest
 
Posts: n/a
Re: Difference in PDO and FDO.

A couple problems here, class driver is confusing so lets use the real term
Function Driver. Also, the function driver may does need to know, for
instance in a case where I had a bus driver that provieded a PDO for two
communication links to IO processors the existing architecture required the
Function driver to know that there were two links (in fact they were
exported as seperate device interfaces) on a single PDO.

While yours is a good rule of thumb description as the example above there
are problems. Put in "for the most part" or similar language for wiggle
room and it is a good "working definition".


--
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
http://www.windrvr.com
Remove StopSpam from the email to reply


<soviet_bloke*************> wrote in message
news:1152936347.718969.32790@p79g2000cwp.googlegro ups.com...
> Hi Don
>
>>Bottom, line PDO is a device object instantiated by a bus driver
>> for the purpose of attaching a Function Device Object to it.

>
> I am afraid your definition of PDO is a bit confusing (at least for
> someone who is new to kernel-mode development).
>
> I would rather say that, from the class driver's point of view, PDO is
> a device object that represents something that acts as a hardware
> device of some certain type. This "something" may be either "real"
> physical device, or the one virtualized in software. Class driver does
> not need to know whether PDO represents a "real" device - it just
> attaches its FDO to PDO, and treats it as a physical hardware device
>
> Anton Bassov
>
>
>
>
> Don Burn wrote:
>> Actually, the following page from the DDK is a good basis:
>>
>> http://msdn.microsoft.com/library/de...ead260.xml.asp
>>
>> Your use of "actual device" is wrong. For instance I've written bus
>> drivers
>> where the PDO they export represents no "actual device" what so ever. I
>> have also written bus drivers where the PDO represents multiple physical
>> devices. Bottom, line PDO is a device object instantiated by a bus
>> driver
>> for the purpose of attaching a Function Device Object to it.
>>
>>
>> --
>> Don Burn (MVP, Windows DDK)
>> Windows 2k/XP/2k3 Filesystem and Driver Consulting
>> http://www.windrvr.com
>> Remove StopSpam from the email to reply
>>
>>
>>
>> "Ali" <abdulrazaq***********> wrote in message
>> news:1152714062.034603.316900@m73g2000cwd.googlegr oups.com...
>> >
>> > PDO:
>> > Represents the actual device which operates directly on the
>> > underlying specific device. Like if we talk about PDO for USB (Assume 2
>> > USBs on system) device or COM port (Assume 2 COMs on system) then it
>> > means that for USB there is another PDO which is a HUB controller PDO
>> > and for HUB controller PDO there is a Main bus PDO and that's it.
>> > This is the PDO which corresponds to COM port PDOs as well. (For
>> > parallel port there is just an single PDO which directly talks to main
>> > bus PDO or it can be possible that it is directly talking to port,
>> > don't know!)
>> >
>> > And putting them together makes a device class like for USB it is USB
>> > class having objects from HUB to Main bus PDOs.
>> >
>> > FDO:
>> > These are the function drivers that makes use of PDOs and they can
>> > be more then one at any given time, say a Bulk FDO, Direct I\O FDO and
>> > so on and so forth.
>> >
>> > Filters:
>> > Ah, making life easier just hanging on top of the stack to process
>> > the interested IRPs ( happenings;-) ) and let the every other stranger
>> > IRP pass through them down to the stack.
>> >
>> >
>> > Lets hear from peers!
>> > ali
>> >

>



 
Unread 02-12-2007, 12:03 AM   #3
Maxim S. Shatskih
Guest
 
Posts: n/a
Re: Difference in PDO and FDO.

> I would rather say that, from the class driver's point of view, PDO is
> a device object that represents something that acts as a hardware
> device of some certain type. This "something" may be either "real"


No. The main purpose of the PDO is to be _bottom-most_ of the device stack. The
PnP's "devnode" structure is attached to a PDO via
DeviceObject->DeviceObjectExtension, this field is NULL for all other DOs.

Lots of stacks use hardware-less PDOs.

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

 
Unread 02-12-2007, 12:03 AM   #4
Don Burn
Guest
 
Posts: n/a
Re: Difference in PDO and FDO.

Actually, the following page from the DDK is a good basis:

http://msdn.microsoft.com/library/de...ead260.xml.asp

Your use of "actual device" is wrong. For instance I've written bus drivers
where the PDO they export represents no "actual device" what so ever. I
have also written bus drivers where the PDO represents multiple physical
devices. Bottom, line PDO is a device object instantiated by a bus driver
for the purpose of attaching a Function Device Object to it.


--
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
http://www.windrvr.com
Remove StopSpam from the email to reply



"Ali" <abdulrazaq***********> wrote in message
news:1152714062.034603.316900@m73g2000cwd.googlegr oups.com...
>
> PDO:
> Represents the actual device which operates directly on the
> underlying specific device. Like if we talk about PDO for USB (Assume 2
> USBs on system) device or COM port (Assume 2 COMs on system) then it
> means that for USB there is another PDO which is a HUB controller PDO
> and for HUB controller PDO there is a Main bus PDO and that's it.
> This is the PDO which corresponds to COM port PDOs as well. (For
> parallel port there is just an single PDO which directly talks to main
> bus PDO or it can be possible that it is directly talking to port,
> don't know!)
>
> And putting them together makes a device class like for USB it is USB
> class having objects from HUB to Main bus PDOs.
>
> FDO:
> These are the function drivers that makes use of PDOs and they can
> be more then one at any given time, say a Bulk FDO, Direct I\O FDO and
> so on and so forth.
>
> Filters:
> Ah, making life easier just hanging on top of the stack to process
> the interested IRPs ( happenings;-) ) and let the every other stranger
> IRP pass through them down to the stack.
>
>
> Lets hear from peers!
> ali
>



 
Unread 02-12-2007, 12:03 AM   #5
Ali
Guest
 
Posts: n/a
Re: Difference in PDO and FDO.


Maxim S. Shatskih wrote:
> > I would rather say that, from the class driver's point of view, PDO is
> > a device object that represents something that acts as a hardware
> > device of some certain type. This "something" may be either "real"

>
> No. The main purpose of the PDO is to be _bottom-most_ of the device stack. The
> PnP's "devnode" structure is attached to a PDO via
> DeviceObject->DeviceObjectExtension, this field is NULL for all other DOs.
>
> Lots of stacks use hardware-less PDOs.
>
> --
> Maxim Shatskih, Windows DDK MVP
> StorageCraft Corporation
> maxim@storagecraft.com
> http://www.storagecraft.com


Don wrote:
>Your use of "actual device" is wrong. For instance I've written bus drivers
>where the PDO they export represents no "actual device" what so ever. I
>have also written bus drivers where the PDO represents multiple physical
>devices. Bottom, line PDO is a device object instantiated by a bus driver
>for the purpose of attaching a Function Device Object to it.


Anton Bassov wrote:
> I would rather say that, from the class driver's point of view, PDO is
> a device object that represents something that acts as a hardware
> device of some certain type. This "something" may be either "real"


Maxim wrote:
> No. The main purpose of the PDO is to be _bottom-most_ of the device stack. The
> PnP's "devnode" structure is attached to a PDO via
> DeviceObject->DeviceObjectExtension, this field is NULL for all other DOs.


Maxim says that it is something (PDO) _bottom_most and Anton is also
saying the same that it is real (PDO) "hardware" or an interface that
directly interacts to hardware. Though Don sounds some how different
like he insists that "bus driver" is something that creates the PDO. Ok
that makes sense also because strictly speaking we know that there are
buses that makes communication from accumulator register to device
register ; e.i. PCI , SCSI, man bus.

Now where is the difference?

Can we put it in these words? that :
1) A system
2) Multiple devices so buses to provide a communication path for
specific device to processor. (Say it a Bus driver which will talk to
hardware abstraction layer).
3) Now device classes (Like tow USBs say one is Type A and second is
Type B , tow serial ports ; one with 9 pins and another with 25 pins,
parallel port; one with 25 pins and second with 36 pins). Say there are
PDOs taking care of that which can help procedding FDOs to identify a
specific device with specific physical layout e.g. 9 pins serial port..
4) Now comes in the FDO that makes PDOs useful for apps, that you put
your FiDOs on them or you just create a symbolic link directly to FDO
to user space to talk. Or some FDOs can really exist in user space as
well


ali

 
Unread 02-12-2007, 12:03 AM   #6
Maxim S. Shatskih
Guest
 
Posts: n/a
Re: Difference in PDO and FDO.

> Maxim says that it is something (PDO) _bottom_most and Anton is also
> saying the same that it is real (PDO) "hardware" or an interface that
> directly interacts to hardware. Though Don sounds some how different
> like he insists that "bus driver" is something that creates the PDO. Ok
> that makes sense also because strictly speaking we know that there are
> buses that makes communication from accumulator register to device
> register ; e.i. PCI , SCSI, man bus.


Well, OK, viewing from another angle:

- the PnP device tree (as in Device Manager) is a lot of devnodes, where some
devnodes have "children", so, there is a tree-like parent-child relationship
between devnodes.
- each devnode contains at least a PDO (and an internal "devnode" structure
connected to the PDO). It can also contain the functional and filter DOs _on
top of the PDO_, so, the picture starts to be 3D :-)
- for a devnode to exist, there must be the parent driver, which creates the
PDOs for the child devnodes and returns them in MN_QUERY_RELATIONS sent to a
parent devnode. All devnodes except the root one are created this way, and the
root devnode is created by the kernel itself.
- the driver which can create "child devnodes" is called "bus driver" or
"enumerator" in MS's terminology. It implements all PDO's work.
- sometimes, a PDO is enough for a devnode, and can contain all functionality
in it. Example: monitor devnodes created by VideoPrt.sys in pre-Vista OSes.
This is called "raw device".
- but more often - especially if there is some physical hardware underlying
this tree branch - at least 2 drivers participate in devnode.
- one driver is the bus driver, which is capable of querying/setting the
_common things for all devices on a bus_, without any knowledge of particular
details of particular device. For instance, any PCI device has config space,
and we have the PCI.SYS bus driver which enumerates the PCI config space and
creates devnodes off it - one per PCI slot (more exacty - for a PCI function).
Any USB device has default contol pipe and config descriptors, and we have the
USBHUB bus driver which enumerates the downstream hub ports, queries the config
descriptors from the connected devices and creates devnodes off them.
- but there must be the second driver, which really "drives" this device and
contains all device-specific logic. This is called the "functional driver", and
it creates the FDOs on top of the PDOs, to handle all device-specific stuff. It
passes all bus-generic stuff down to the PDO. This is really the driver for the
read device, not for the PCI slot or for the downstream USB hub port.
- now there is a question on how the correct functional driver is found for the
devnode. The answer is - the functional driver's software package contains the
INF file, which maps the "hardware ID" to the particular functional driver. The
OS scans all existing INFs to find the one matching the hardware ID of the
devnode.
- the "hardware ID" is a string, its format is BusName\BusSpecificData. The
BusSpecificData layout depends on a bus, for instance, for PCI, it is
VEN_xxx&DEV_XXX&SUBSYS_xxx, where the values are queried from the PCI config
space for this hardware device.
- the bus driver must respond to MN_QUERY_ID for its PDOs and return these
strings. For instance, the PCI.SYS enumerator creates the "PCI\VEN_
04x&DEV_%04x" string, with vendor and device IDs got from the config space.

This is a bit simplified, lots of small details are omitted, for them - read
MSDN Library or Walter Oney's book.

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

 
Unread 02-12-2007, 12:05 AM   #7
Maxim S. Shatskih
Guest
 
Posts: n/a
Re: Difference in PDO and FDO.

> Say a driver for main bus , right? Which is directly talking to HAL.

No. It enumerates the registry entries created manually (by Add New Hardware
wizard for non-PnP) or automatically (non-PnP hardware detection during Windows
setup).

One of the children of the root enum is the "ACPI PC" devnode, which is the
BIOS's ACPI tables.

As about HAL - it contains the code to talk to interrupt controllers and
timers, to do SMP interprocessor interrupts, and also some ACPI stuff. It helps
the ACPI.SYS driver in enumerating the ACPI tables.

> Yes before getting the CPU there should be a way for root "devnode"
> to tell the processor that what kind of device it is.


This became necessary only for XP+ with Intel's floating CPU clock feature
support. Before it, the CPU had no driver and was not presented in the PnP
tree.

> for any node to exist without parent so I would rephrase that "for a
> devnode to exist, there must be the parent driver and if it is not then
> the root serves as a parent" , right?


No. Devnodes are _created_ by the parent driver, which can be the root one -
this is more exact.

> Can I consider parport.sys module in above category?


Don't remember.

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

 
Unread 02-12-2007, 12:09 AM   #8
Ali
Guest
 
Posts: n/a
Re: Difference in PDO and FDO.


Don Burn wrote:
> Actually, the following page from the DDK is a good basis:
>
> http://msdn.microsoft.com/library/de...ead260.xml.asp
>
> Your use of "actual device" is wrong. For instance I've written bus drivers
> where the PDO they export represents no "actual device" what so ever. I
> have also written bus drivers where the PDO represents multiple physical
> devices. Bottom, line PDO is a device object instantiated by a bus driver
> for the purpose of attaching a Function Device Object to it.
>
>
> --
> Don Burn (MVP, Windows DDK)
> Windows 2k/XP/2k3 Filesystem and Driver Consulting
> http://www.windrvr.com
> Remove StopSpam from the email to reply
>
>
>
> "Ali" <abdulrazaq***********> wrote in message
> news:1152714062.034603.316900@m73g2000cwd.googlegr oups.com...
> >
> > PDO:
> > Represents the actual device which operates directly on the
> > underlying specific device. Like if we talk about PDO for USB (Assume 2
> > USBs on system) device or COM port (Assume 2 COMs on system) then it
> > means that for USB there is another PDO which is a HUB controller PDO
> > and for HUB controller PDO there is a Main bus PDO and that's it.
> > This is the PDO which corresponds to COM port PDOs as well. (For
> > parallel port there is just an single PDO which directly talks to main
> > bus PDO or it can be possible that it is directly talking to port,
> > don't know!)
> >
> > And putting them together makes a device class like for USB it is USB
> > class having objects from HUB to Main bus PDOs.
> >
> > FDO:
> > These are the function drivers that makes use of PDOs and they can
> > be more then one at any given time, say a Bulk FDO, Direct I\O FDO and
> > so on and so forth.
> >
> > Filters:
> > Ah, making life easier just hanging on top of the stack to process
> > the interested IRPs ( happenings;-) ) and let the every other stranger
> > IRP pass through them down to the stack.
> >
> >
> > Lets hear from peers!
> > ali
> >

Me and my friend were having really big difference on this issue and
that link explains a lot.
Don! thanks for that it was super good pointer. Can you put some words
for 'class'.? What makes a class ? when it comes to NT driver world.

ali

 
Unread 02-12-2007, 12:09 AM   #9
Don Burn
Guest
 
Posts: n/a
Re: Difference in PDO and FDO.


"Ali" <abdulrazaq***********> wrote in message
> Me and my friend were having really big difference on this issue and
> that link explains a lot.
> Don! thanks for that it was super good pointer. Can you put some words
> for 'class'.? What makes a class ? when it comes to NT driver world.


Ali,

Again I will give you a link,
http://msdn.microsoft.com/library/de...724c5b.xml.asp

In general a device class indicates the driver provides a type of
interface, for instance a SCSI miniport provides (with the port driver) a
SCSI device class interfacem, that has a well known set of charateristics
and functions.

For the case of a device that does not meet a Microsoft class, you create
your own class along with an interface for that class.

--
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
http://www.windrvr.com
Remove StopSpam from the email to reply




 
Unread 02-12-2007, 12:09 AM   #10
Ali
Guest
 
Posts: n/a
Re: Difference in PDO and FDO.


Don Burn wrote:
> "Ali" <abdulrazaq***********> wrote in message
> > Me and my friend were having really big difference on this issue and
> > that link explains a lot.
> > Don! thanks for that it was super good pointer. Can you put some words
> > for 'class'.? What makes a class ? when it comes to NT driver world.

>
> Ali,
>
> Again I will give you a link,
> http://msdn.microsoft.com/library/de...724c5b.xml.asp
>
> In general a device class indicates the driver provides a type of
> interface, for instance a SCSI miniport provides (with the port driver) a
> SCSI device class interfacem, that has a well known set of charateristics
> and functions.
>
> For the case of a device that does not meet a Microsoft class, you create
> your own class along with an interface for that class.
>
> --
> Don Burn (MVP, Windows DDK)
> Windows 2k/XP/2k3 Filesystem and Driver Consulting
> http://www.windrvr.com
> Remove StopSpam from the email to reply


Thank you very much let me have a look at that.

Regards,
ali

 
 

Thread Tools
Display Modes



< Home - Windows Help - MS Office Help - Hardware Support >


New To Site? Need Help?

All times are GMT. The time now is 05:17 AM.


vBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO
Copyright © 2005-2013, TechTalkz.com. All Rights Reserved - Privacy Policy
Valid XHTML 1.0 Transitional