Multiple FDOs for a Single PDO ?

NTDEV
1

Hello,

Is it possible for a SINGLE PhysicalDeviceObject to have MULTIPLE (more
than just 1) FunctionalDeviceObjects on top of it ?

Basically I have a device A which has three different functionalities (F1,
F2 and F3), and I want to create a separate DeviceObject for each
functionality of the device, so that the user can access each functionality
separately. How can I achieve this:

  1. Can I have ONE PDO for Device A; ONE FDO for F1, SECOND FDO for F2 and
    THIRD FDO for F3 ?

OR

  1. Do I need THREE PDOs for Device A (one each for F1, F2 and F3);
    Corresponding FDOs (ONE for F1, SECOND for F2 and THIRD for F3) ?

And if its #1, do I just call IoCreateDevice() multiple times in my
AddDevice() ?

Is there any relevant example ? Any information or pointers are
appreciated.

Thanks much,
Puja

2

you cannot have 3 fdos over 1 pdo.
this limitation I believe is imposed because otherwise the Pnp manager will
not know to which fdo the pnp calls are to be routed.

you have 2 alternatives

  1. make 1 fdo and the other 2 filter DOs
  2. make 3 pdos and corresponding fdos.

regards
jeseem
mailto:xxxxx@hotmail.com
http://www.nesttech.com

----- Original Message -----
From:
To: “NT Developers Interest List”
Sent: Thursday, August 17, 2000 5:21 PM
Subject: [ntdev] Multiple FDOs for a Single PDO ?

> Hello,
>
> Is it possible for a SINGLE PhysicalDeviceObject to have MULTIPLE (more
> than just 1) FunctionalDeviceObjects on top of it ?
>
> Basically I have a device A which has three different functionalities (F1,
> F2 and F3), and I want to create a separate DeviceObject for each
> functionality of the device, so that the user can access each
functionality
> separately. How can I achieve this:
>
> 1. Can I have ONE PDO for Device A; ONE FDO for F1, SECOND FDO for F2 and
> THIRD FDO for F3 ?
>
> OR
>
> 2. Do I need THREE PDOs for Device A (one each for F1, F2 and F3);
> Corresponding FDOs (ONE for F1, SECOND for F2 and THIRD for F3) ?
>
> And if its #1, do I just call IoCreateDevice() multiple times in my
> AddDevice() ?
>
> Is there any relevant example ? Any information or pointers are
> appreciated.
>
> Thanks much,
> Puja
>
> —
> You are currently subscribed to ntdev as: xxxxx@hotmail.com
> To unsubscribe send a blank email to $subst(‘Email.Unsub’)
>
>

3

Hello,

I noticed in the OSR Device Driver Book, Chapter 9, Page 178, there is a
mention of multiple Device Objects, but since it is for WinNT and not Win2K,
it doesn’t distinguish between PDOs and FDOs. I would think that it is
referring to the FDO (since it is the Function/Device Driver that it is
talking about). Am I correct ?

Also, if we can have multiple FDOs, then they should be possible on a single
PDO (because otherwise doesn’t it mean that we would have to modify the
corresponding Bus Driver to create multiple PDOs for the device it enumerates,
and my understanding is that Bus Drivers are standard). Is this correct ?

Thanks for your help.

Thanks
Puja

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Jeseem
Sent: Thursday, August 17, 2000 2:42 PM
To: NT Developers Interest List
Subject: [ntdev] Re: Multiple FDOs for a Single PDO ?

you cannot have 3 fdos over 1 pdo.
this limitation I believe is imposed because otherwise the Pnp manager will
not know to which fdo the pnp calls are to be routed.

you have 2 alternatives

  1. make 1 fdo and the other 2 filter DOs
  2. make 3 pdos and corresponding fdos.

regards
jeseem
mailto:xxxxx@hotmail.com
http://www.nesttech.com

----- Original Message -----
From:
> To: “NT Developers Interest List”
> Sent: Thursday, August 17, 2000 5:21 PM
> Subject: [ntdev] Multiple FDOs for a Single PDO ?
>
>
> > Hello,
> >
> > Is it possible for a SINGLE PhysicalDeviceObject to have MULTIPLE (more
> > than just 1) FunctionalDeviceObjects on top of it ?
> >
> > Basically I have a device A which has three different functionalities
(F1,
> > F2 and F3), and I want to create a separate DeviceObject for each
> > functionality of the device, so that the user can access each
> functionality
> > separately. How can I achieve this:
> >
> > 1. Can I have ONE PDO for Device A; ONE FDO for F1, SECOND FDO for F2 and
> > THIRD FDO for F3 ?
> >
> > OR
> >
> > 2. Do I need THREE PDOs for Device A (one each for F1, F2 and F3);
> > Corresponding FDOs (ONE for F1, SECOND for F2 and THIRD for F3) ?
> >
> > And if its #1, do I just call IoCreateDevice() multiple times in my
> > AddDevice() ?
> >
> > Is there any relevant example ? Any information or pointers are
> > appreciated.
> >
> > Thanks much,
> > Puja

____________________________________________________________________
Get free email and a permanent address at http://www.amexmail.com/?A=1

4

>

I noticed in the OSR Device Driver Book, Chapter 9, Page 178, there is a
mention of multiple Device Objects, but since it is for WinNT and
not Win2K,
it doesn’t distinguish between PDOs and FDOs. I would think that it is
referring to the FDO (since it is the Function/Device Driver that it is
talking about). Am I correct ?

There is nothing equivalent in NT4 to the PDO-FDO relationship in W2K. How a
driver chose to represent IO paths using device objects was entirely up to
each driver, or each stack of related drivers.

Also, if we can have multiple FDOs, then they should be possible
on a single
PDO (because otherwise doesn’t it mean that we would have to modify the
corresponding Bus Driver to create multiple PDOs for the device
it enumerates,
and my understanding is that Bus Drivers are standard). Is this correct ?

You really can’t have multiple FDOs for a PDO. Each PDO has a PnP
enumeration ID, and the PnP manager uses that ID to select a single Driver
as the target for an AddDevice operation. Now of course in your AddDevice
routine you could create all sorts of device objects for whatever reason you
desire, but only the one attached to the PDO is going to be within the PnP
architecture.

If you really want to have several IO targets represented as device objects,
then the PnP/WDM way to do this is to create an abstract IO bus and treat
the FDO of the original PDO as a bus driver FDO and have it respond to bus
enumeration requests and have it create new PDOs for its bus, and have
drivers registered as the function drivers for these new PDOs. See the
toaster bus driver for some clues as to how this can be done. Note that
there is nothing other than increased complexity that prevents you from
having a single driver module that is the bus driver for the original FDO,
and the function driver for each of your enumerated PDOs. See for example
what the disk class driver (and the classpnp library) is doing to create an
abstract bus at the disk level.

5

Thanks for the explanation, Mark. I do have one question: would the FDO of
the original PDO (in your example below) be connected to the new PDOs above
it ? Or would these stacks be totally independent of each-other ?

The DDK and Walter Oney’s book (Pg 23, Fig 2.2) show a link between these
two.
Would the IRPs be passed down via this link to the lower Driver ?

Thanks for the clarification.
Puja

If you really want to have several IO targets represented as device objects,
then the PnP/WDM way to do this is to create an abstract IO bus and treat
the FDO of the original PDO as a bus driver FDO and have it respond to bus
enumeration requests and have it create new PDOs for its bus, and have
drivers registered as the function drivers for these new PDOs. See the
toaster bus driver for some clues as to how this can be done. Note that
there is nothing other than increased complexity that prevents you from
having a single driver module that is the bus driver for the original FDO,
and the function driver for each of your enumerated PDOs.

6

I think I found an answer to my question further down in Walter Oney’s
book, with examples!

Thanks anyway,
Puja

On 08/21/00, “xxxxx@usa.net” wrote:

Thanks for the explanation, Mark. I do have one question: would the FDO of
the original PDO (in your example below) be connected to the new PDOs
above
it ? Or would these stacks be totally independent of each-other ?

The DDK and Walter Oney’s book (Pg 23, Fig 2.2) show a link between these
two.
Would the IRPs be passed down via this link to the lower Driver ?

Thanks for the clarification.
Puja

7

>

Thanks for the explanation, Mark. I do have one question: would
the FDO of
the original PDO (in your example below) be connected to the new
PDOs above
it ? Or would these stacks be totally independent of each-other ?

It does get confusing. We have two flavors of PDOs and two flavors of FDOs.
Lets call PDO-1 the PDO created by some other bus driver (a hardware bus
driver in your case, but that doesn’t matter.) Your driver is regestered as
the function driver for whatever the PnP ID of PDO-1 is. When a PDO-1 is
enumerated your driver is loaded if required and called at your AddDevice
interface with a pointer to an instance of a PDO-1 device object. You create
an FDO (which we will refer to as an FDO-1 FDO.) You attach your FDO-1
device object and we now have a stack like so:

FDO-1
|

Driver 2
Driver 1
PDO-1

There is a direct device object relationship between FDO-1 and PDO-1. FDO-1
is on the linked list of attached devices that exists in the PDO-1 device
object.

Some time later your bus driver role in your driver enumerates three PDOs,
all of them type PDO-2 (they could actually be different PnP types, as in
PDO-2a PDO-2b PDO-2c but that is way too complicated for now and changes
nothing relevent.) The relationship between FDO-1 and its enumerated PDO-2
device objects is NOT a direct stacking relationship as in the relationship
between FDO-1 and PDO-1. Instead the picture looks something like this:
FDO-2 FDO-2 FDO-2
| | |
| Driver 3 | |

| | |
FDO-1 | | |
| PDO-2 PDO-2 PDO-2

Driver 2
Driver 1
PDO-1

PDO-2 is not ‘attached’ or ‘stacked’ above FDO-1 or PDO-1. If an IRP is
passed from a PDO02 pdo to FDO-1 (and from there to PDO-1) that is a
function of an internal design of Driver-2 and not part of the Wdm design.
Whatever driver is registered as the function driver for PDO-2 pdos has its
own FDO-2 type FDOs attached above your PDO-2 pdos, just as your FDO-1 fdo
is attached above some other driver’s PDO-1 pdo.

This can of course recurse again in driver3 as each FDO-2 fdo could function
as a bus driver fdo and create its own set of PDOs (PDO-3 pdos.) It is also
quite possible that the FDO-2 fdos are in fact created by Driver-2 as
Driver-2 could register as the function driver for both PDO-1 pdos and PDO-2
pdos.

The DDK and Walter Oney’s book (Pg 23, Fig 2.2) show a link between these
two.

The illustration is unclear about what the arrows mean. I think that walter
means that there is “a relationship” shown by the arrows, without defining
what that relationship is or if it is always the same for any arrow
connecting any box. The relationship between a bus driver FDO (FDO-1 above)
and its enumerated PDO(s) (PDO-2 above) is a parent/child relationship.

The PnP manager understands that all the PDO-2s in the picture above ‘belong
to’ FDO-1 because FDO-1 built a reply to an IRP_MN_QUERY_DEVICE_RELATIONS
pnp IRP of subtype BusRelations that listed each of these three PDOs. Other
than this, there is no PnP architected connection between each PDO-2 and its
enumerating FDO.