Multi Functional PCI Device Driver

NTDEV
1

I am currently developing a PCI device driver, so far so good, since I am
able to talk to the PCI device. however I have come across a design issue.

This PCI Device has four I/O interfaces, each interface has its own
allocated internal buffer on the PCI card.

I/O Interface Port A
I/O Interface Port B
I/O Interface Port C
I/O Interface Port D

Unfortunately with the CreateFile operation you can not specify which I/O
Interface you wish to use, unless you send a DeviceIoControl command down to
the driver after it has opened to define which Interface the user wish to
use.

I need the facility to be able to read from more than one I/O interface, so
my question is this… is it possible to perhaps load a device driver for
each I/O interface on the PCI card, effectively having 4 instances of the
driver so that it can allocate any resources necessary to handle subsequent
I/O requests.

It must be possible since I’ve seen PCI cards with combined USB, Ethernet
and Firewire controllers built onto a single PCI card.

or is there another way to handle this?

This email and any files attached are intended for the addressee and may
contain information of a confidential nature. If you are not the intended
recipient, be aware that this email was sent to you in error and you should
not disclose, distribute, print, copy or make other use of this email or its
attachments. Such actions, in fact, may be unlawful. In compliance with
the various Regulations and Acts, General Dynamics UK Limited reserves the
right to monitor (and examine for viruses) all emails and email attachments,
both inbound and outbound. Email communications and their attachments may
not be secure or error- or virus-free and the company does not accept
liability or responsibility for such matters or the consequences thereof.
Registered Office: 100 New Bridge Street, London EC4V 6JA. Registered in
England and Wales No: 1911653.

2

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of James Dunning
Sent: Wednesday, October 26, 2005 4:00 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Multi Functional PCI Device Driver

I am currently developing a PCI device driver, so far so good, since I
am
able to talk to the PCI device. however I have come across a design
issue.

This PCI Device has four I/O interfaces, each interface has its own
allocated internal buffer on the PCI card.

I/O Interface Port A
I/O Interface Port B
I/O Interface Port C
I/O Interface Port D

Are you talking about four function on same card or pci card with four
i/o > registers?

Unfortunately with the CreateFile operation you can not specify which
I/O
Interface you wish to use, unless you send a DeviceIoControl command
down to
the driver after it has opened to define which Interface the user wish
to
use.

I need the facility to be able to read from more than one I/O interface,
so
my question is this… is it possible to perhaps load a device driver
for
each I/O interface on the PCI card, effectively having 4 instances of
the
driver so that it can allocate any resources necessary to handle
subsequent
I/O requests.

It must be possible since I’ve seen PCI cards with combined USB,
Ethernet
and Firewire controllers built onto a single PCI card.

These cards have multiple functions.

or is there another way to handle this?

This email and any files attached are intended for the addressee and may
contain information of a confidential nature. If you are not the
intended
recipient, be aware that this email was sent to you in error and you
should
not disclose, distribute, print, copy or make other use of this email or
its
attachments. Such actions, in fact, may be unlawful. In compliance
with
the various Regulations and Acts, General Dynamics UK Limited reserves
the
right to monitor (and examine for viruses) all emails and email
attachments,
both inbound and outbound. Email communications and their attachments
may
not be secure or error- or virus-free and the company does not accept
liability or responsibility for such matters or the consequences
thereof.
Registered Office: 100 New Bridge Street, London EC4V 6JA. Registered
in
England and Wales No: 1911653.

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

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

3

I might have answered my own question! but I am assuming all I need to do is
during the PNP AddDevice routine is create four Functional DeviceObjects,
and initialise the DeviceExtention for the I/O Interface Port.

Afterall the idea is to be able to handle up to four peripheral devices
connected to the PCI card, effectively each I/O Interface has its own
function.

Is this the approach I should take?

Regards

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of
xxxxx@wipro.com
Sent: 26 October 2005 11:53
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Multi Functional PCI Device Driver

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of James Dunning
Sent: Wednesday, October 26, 2005 4:00 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Multi Functional PCI Device Driver

I am currently developing a PCI device driver, so far so good, since I
am
able to talk to the PCI device. however I have come across a design
issue.

This PCI Device has four I/O interfaces, each interface has its own
allocated internal buffer on the PCI card.

I/O Interface Port A
I/O Interface Port B
I/O Interface Port C
I/O Interface Port D

Are you talking about four function on same card or pci card with four
i/o > registers?

Unfortunately with the CreateFile operation you can not specify which
I/O
Interface you wish to use, unless you send a DeviceIoControl command
down to
the driver after it has opened to define which Interface the user wish
to
use.

I need the facility to be able to read from more than one I/O interface,
so
my question is this… is it possible to perhaps load a device driver
for
each I/O interface on the PCI card, effectively having 4 instances of
the
driver so that it can allocate any resources necessary to handle
subsequent
I/O requests.

It must be possible since I’ve seen PCI cards with combined USB,
Ethernet
and Firewire controllers built onto a single PCI card.

These cards have multiple functions.

or is there another way to handle this?

This email and any files attached are intended for the addressee and may
contain information of a confidential nature. If you are not the
intended
recipient, be aware that this email was sent to you in error and you
should
not disclose, distribute, print, copy or make other use of this email or
its
attachments. Such actions, in fact, may be unlawful. In compliance
with
the various Regulations and Acts, General Dynamics UK Limited reserves
the
right to monitor (and examine for viruses) all emails and email
attachments,
both inbound and outbound. Email communications and their attachments
may
not be secure or error- or virus-free and the company does not accept
liability or responsibility for such matters or the consequences
thereof.
Registered Office: 100 New Bridge Street, London EC4V 6JA. Registered
in
England and Wales No: 1911653.

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

You are currently subscribed to ntdev as: xxxxx@wipro.com
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: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com
This email and any files attached are intended for the addressee and may
contain information of a confidential nature. If you are not the intended
recipient, be aware that this email was sent to you in error and you should
not disclose, distribute, print, copy or make other use of this email or its
attachments. Such actions, in fact, may be unlawful. In compliance with
the various Regulations and Acts, General Dynamics UK Limited reserves the
right to monitor (and examine for viruses) all emails and email attachments,
both inbound and outbound. Email communications and their attachments may
not be secure or error- or virus-free and the company does not accept
liability or responsibility for such matters or the consequences thereof.
Registered Office: 100 New Bridge Street, London EC4V 6JA. Registered in
England and Wales No: 1911653.

4

> Unfortunately with the CreateFile operation you can not specify which I/O

Interface you wish to use

Why not? Use the reference strings like \.\MyDevice\IoInterface0 and so on.
The MJ_CREATE path will look at FileObject->FileName and compare it to
\IoInterface0.

my question is this… is it possible to perhaps load a device driver for
each I/O interface on the PCI card, effectively having 4 instances of the
driver so that it can allocate any resources necessary to handle subsequent
I/O requests.

Possibly too, if the 4 interfaces are not dependent on each other. This is done
by mf.sys. Read the docs on mf.sys, the INF file samples are Microsoft-provided
INFs for Aureal Vortex soundcard.

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

5

No. This will not work. You are trying to implement a bus driver with
your approach and that is not the way to do it.

There are two approaches that can work for you. The simplest is to
create a namespace for your device. This is just a convention that your
applications and your driver know about. Your function driver creates a
device interface (a named device object visible to user mode), for
simplicity lets say the name for the interface is \DosDevices\Foo. Your
applications open \DosDevices\Foo\Channel1 or open
\DosDevices\Foo\Channel2 or … Your driver checks the FileObject name
used on IRP_MJ_CREATE, finds either nothing or Channel1 or Channel2 or
… and (hand waving alert) you are done.

More complicated is to push your design into the multifunction driver
model that is supplied with the OS. This will do what you were trying to
do with your ‘create four Function Devices in AddDevice’ approach, only
it will actually work :-). I suggest the first approach, but you can
search this list and the DDK for more information on the multifunction
driver approach as well.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of James Dunning
Sent: Wednesday, October 26, 2005 7:12 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Multi Functional PCI Device Driver

I might have answered my own question! but I am assuming all I need to
do is
during the PNP AddDevice routine is create four Functional
DeviceObjects,
and initialise the DeviceExtention for the I/O Interface Port.

Afterall the idea is to be able to handle up to four peripheral devices
connected to the PCI card, effectively each I/O Interface has its own
function.

Is this the approach I should take?

Regards

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of
xxxxx@wipro.com
Sent: 26 October 2005 11:53
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Multi Functional PCI Device Driver

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of James Dunning
Sent: Wednesday, October 26, 2005 4:00 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Multi Functional PCI Device Driver

I am currently developing a PCI device driver, so far so good, since I
am
able to talk to the PCI device. however I have come across a design
issue.

This PCI Device has four I/O interfaces, each interface has its own
allocated internal buffer on the PCI card.

I/O Interface Port A
I/O Interface Port B
I/O Interface Port C
I/O Interface Port D

Are you talking about four function on same card or pci card with four
i/o > registers?

Unfortunately with the CreateFile operation you can not specify which
I/O
Interface you wish to use, unless you send a DeviceIoControl command
down to
the driver after it has opened to define which Interface the user wish
to
use.

I need the facility to be able to read from more than one I/O interface,
so
my question is this… is it possible to perhaps load a device driver
for
each I/O interface on the PCI card, effectively having 4 instances of
the
driver so that it can allocate any resources necessary to handle
subsequent
I/O requests.

It must be possible since I’ve seen PCI cards with combined USB,
Ethernet
and Firewire controllers built onto a single PCI card.

These cards have multiple functions.

or is there another way to handle this?

This email and any files attached are intended for the addressee and may
contain information of a confidential nature. If you are not the
intended
recipient, be aware that this email was sent to you in error and you
should
not disclose, distribute, print, copy or make other use of this email or
its
attachments. Such actions, in fact, may be unlawful. In compliance
with
the various Regulations and Acts, General Dynamics UK Limited reserves
the
right to monitor (and examine for viruses) all emails and email
attachments,
both inbound and outbound. Email communications and their attachments
may
not be secure or error- or virus-free and the company does not accept
liability or responsibility for such matters or the consequences
thereof.
Registered Office: 100 New Bridge Street, London EC4V 6JA. Registered
in
England and Wales No: 1911653.

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

You are currently subscribed to ntdev as: xxxxx@wipro.com
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: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com
This email and any files attached are intended for the addressee and may
contain information of a confidential nature. If you are not the
intended
recipient, be aware that this email was sent to you in error and you
should
not disclose, distribute, print, copy or make other use of this email or
its
attachments. Such actions, in fact, may be unlawful. In compliance
with
the various Regulations and Acts, General Dynamics UK Limited reserves
the
right to monitor (and examine for viruses) all emails and email
attachments,
both inbound and outbound. Email communications and their attachments
may
not be secure or error- or virus-free and the company does not accept
liability or responsibility for such matters or the consequences
thereof.
Registered Office: 100 New Bridge Street, London EC4V 6JA. Registered
in
England and Wales No: 1911653.

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

6

Hi Mark,

I can see what you are trying to say, basically if I register a device
interface with a symbolic link with something along the lines of
\DosDevices\Foo, I can tag a string on the end of the \DosDevices\Foo and
this would simply be passed down to IRP_MJ_CREATE, when the application
opens the device

so if my application opens \DosDevices\Foo\Channel1 my driver could process
the string “Channel1” and configure that channel accordingly.

However here’s my problem. lets say I want to read from Channel 1 and
Channel 2 simultaneously. How would IRP_MJ_READ know whether the requested
read operation was for the channel 1 or channel 2 interface? this is why I
am wondering whether it would be easier to have 4 functional devices for the
PCI card.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Roddy, Mark
Sent: 26 October 2005 14:06
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Multi Functional PCI Device Driver

No. This will not work. You are trying to implement a bus driver with
your approach and that is not the way to do it.

There are two approaches that can work for you. The simplest is to
create a namespace for your device. This is just a convention that your
applications and your driver know about. Your function driver creates a
device interface (a named device object visible to user mode), for
simplicity lets say the name for the interface is \DosDevices\Foo. Your
applications open \DosDevices\Foo\Channel1 or open
\DosDevices\Foo\Channel2 or … Your driver checks the FileObject name
used on IRP_MJ_CREATE, finds either nothing or Channel1 or Channel2 or
… and (hand waving alert) you are done.

More complicated is to push your design into the multifunction driver
model that is supplied with the OS. This will do what you were trying to
do with your ‘create four Function Devices in AddDevice’ approach, only
it will actually work :-). I suggest the first approach, but you can
search this list and the DDK for more information on the multifunction
driver approach as well.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of James Dunning
Sent: Wednesday, October 26, 2005 7:12 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Multi Functional PCI Device Driver

I might have answered my own question! but I am assuming all I need to
do is
during the PNP AddDevice routine is create four Functional
DeviceObjects,
and initialise the DeviceExtention for the I/O Interface Port.

Afterall the idea is to be able to handle up to four peripheral devices
connected to the PCI card, effectively each I/O Interface has its own
function.

Is this the approach I should take?

Regards

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of
xxxxx@wipro.com
Sent: 26 October 2005 11:53
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Multi Functional PCI Device Driver

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of James Dunning
Sent: Wednesday, October 26, 2005 4:00 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Multi Functional PCI Device Driver

I am currently developing a PCI device driver, so far so good, since I
am
able to talk to the PCI device. however I have come across a design
issue.

This PCI Device has four I/O interfaces, each interface has its own
allocated internal buffer on the PCI card.

I/O Interface Port A
I/O Interface Port B
I/O Interface Port C
I/O Interface Port D

Are you talking about four function on same card or pci card with four
i/o > registers?

Unfortunately with the CreateFile operation you can not specify which
I/O
Interface you wish to use, unless you send a DeviceIoControl command
down to
the driver after it has opened to define which Interface the user wish
to
use.

I need the facility to be able to read from more than one I/O interface,
so
my question is this… is it possible to perhaps load a device driver
for
each I/O interface on the PCI card, effectively having 4 instances of
the
driver so that it can allocate any resources necessary to handle
subsequent
I/O requests.

It must be possible since I’ve seen PCI cards with combined USB,
Ethernet
and Firewire controllers built onto a single PCI card.

These cards have multiple functions.

or is there another way to handle this?

This email and any files attached are intended for the addressee and may
contain information of a confidential nature. If you are not the
intended
recipient, be aware that this email was sent to you in error and you
should
not disclose, distribute, print, copy or make other use of this email or
its
attachments. Such actions, in fact, may be unlawful. In compliance
with
the various Regulations and Acts, General Dynamics UK Limited reserves
the
right to monitor (and examine for viruses) all emails and email
attachments,
both inbound and outbound. Email communications and their attachments
may
not be secure or error- or virus-free and the company does not accept
liability or responsibility for such matters or the consequences
thereof.
Registered Office: 100 New Bridge Street, London EC4V 6JA. Registered
in
England and Wales No: 1911653.

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

You are currently subscribed to ntdev as: xxxxx@wipro.com
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: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com
This email and any files attached are intended for the addressee and may
contain information of a confidential nature. If you are not the
intended
recipient, be aware that this email was sent to you in error and you
should
not disclose, distribute, print, copy or make other use of this email or
its
attachments. Such actions, in fact, may be unlawful. In compliance
with
the various Regulations and Acts, General Dynamics UK Limited reserves
the
right to monitor (and examine for viruses) all emails and email
attachments,
both inbound and outbound. Email communications and their attachments
may
not be secure or error- or virus-free and the company does not accept
liability or responsibility for such matters or the consequences
thereof.
Registered Office: 100 New Bridge Street, London EC4V 6JA. Registered
in
England and Wales No: 1911653.

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

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
This email and any files attached are intended for the addressee and may
contain information of a confidential nature. If you are not the intended
recipient, be aware that this email was sent to you in error and you should
not disclose, distribute, print, copy or make other use of this email or its
attachments. Such actions, in fact, may be unlawful. In compliance with
the various Regulations and Acts, General Dynamics UK Limited reserves the
right to monitor (and examine for viruses) all emails and email attachments,
both inbound and outbound. Email communications and their attachments may
not be secure or error- or virus-free and the company does not accept
liability or responsibility for such matters or the consequences thereof.
Registered Office: 100 New Bridge Street, London EC4V 6JA. Registered in
England and Wales No: 1911653.

7

I would also suggest the namespace variant. If you want to open channel1
and channel2 then it’s straightforward:
Open chanel1 and channel2, you get two handles. This is same as if you
created two devices…

Robin

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of James Dunning
Sent: Mittwoch, 26. Oktober 2005 15:33
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Multi Functional PCI Device Driver

Hi Mark,

I can see what you are trying to say, basically if I register a device
interface with a symbolic link with something along the lines of
\DosDevices\Foo, I can tag a string on the end of the \DosDevices\Foo
and
this would simply be passed down to IRP_MJ_CREATE, when the application
opens the device

so if my application opens \DosDevices\Foo\Channel1 my driver could
process
the string “Channel1” and configure that channel accordingly.

However here’s my problem. lets say I want to read from Channel 1 and
Channel 2 simultaneously. How would IRP_MJ_READ know whether the
requested
read operation was for the channel 1 or channel 2 interface? this is
why I
am wondering whether it would be easier to have 4 functional devices for
the
PCI card.

8

The BulkUSB sample in the DDK shows this approach if you’re looking for an
example… You’re passed the same PFILE_OBJECT from the create to all of your
I/O dispatch entry points, so you can use this to know which open instance
the I/O you’re receiving is against.

-scott

–
Scott Noone
Software Engineer
OSR Open Systems Resources, Inc.
http://www.osronline.com

“James Dunning” wrote in message
news:xxxxx@ntdev…
> Hi Mark,
>
> I can see what you are trying to say, basically if I register a device
> interface with a symbolic link with something along the lines of
> \DosDevices\Foo, I can tag a string on the end of the \DosDevices\Foo and
> this would simply be passed down to IRP_MJ_CREATE, when the application
> opens the device
>
> so if my application opens \DosDevices\Foo\Channel1 my driver could
> process
> the string “Channel1” and configure that channel accordingly.
>
> However here’s my problem. lets say I want to read from Channel 1 and
> Channel 2 simultaneously. How would IRP_MJ_READ know whether the requested
> read operation was for the channel 1 or channel 2 interface? this is why
> I
> am wondering whether it would be easier to have 4 functional devices for
> the
> PCI card.
>
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com]On Behalf Of Roddy, Mark
> Sent: 26 October 2005 14:06
> To: Windows System Software Devs Interest List
> Subject: RE: [ntdev] Multi Functional PCI Device Driver
>
>
> No. This will not work. You are trying to implement a bus driver with
> your approach and that is not the way to do it.
>
> There are two approaches that can work for you. The simplest is to
> create a namespace for your device. This is just a convention that your
> applications and your driver know about. Your function driver creates a
> device interface (a named device object visible to user mode), for
> simplicity lets say the name for the interface is \DosDevices\Foo. Your
> applications open \DosDevices\Foo\Channel1 or open
> \DosDevices\Foo\Channel2 or … Your driver checks the FileObject name
> used on IRP_MJ_CREATE, finds either nothing or Channel1 or Channel2 or
> … and (hand waving alert) you are done.
>
> More complicated is to push your design into the multifunction driver
> model that is supplied with the OS. This will do what you were trying to
> do with your ‘create four Function Devices in AddDevice’ approach, only
> it will actually work :-). I suggest the first approach, but you can
> search this list and the DDK for more information on the multifunction
> driver approach as well.
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of James Dunning
> Sent: Wednesday, October 26, 2005 7:12 AM
> To: Windows System Software Devs Interest List
> Subject: RE: [ntdev] Multi Functional PCI Device Driver
>
> I might have answered my own question! but I am assuming all I need to
> do is
> during the PNP AddDevice routine is create four Functional
> DeviceObjects,
> and initialise the DeviceExtention for the I/O Interface Port.
>
> Afterall the idea is to be able to handle up to four peripheral devices
> connected to the PCI card, effectively each I/O Interface has its own
> function.
>
> Is this the approach I should take?
>
> Regards
>
>
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com]On Behalf Of
> xxxxx@wipro.com
> Sent: 26 October 2005 11:53
> To: Windows System Software Devs Interest List
> Subject: RE: [ntdev] Multi Functional PCI Device Driver
>
>
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of James Dunning
> Sent: Wednesday, October 26, 2005 4:00 PM
> To: Windows System Software Devs Interest List
> Subject: [ntdev] Multi Functional PCI Device Driver
>
> I am currently developing a PCI device driver, so far so good, since I
> am
> able to talk to the PCI device. however I have come across a design
> issue.
>
> This PCI Device has four I/O interfaces, each interface has its own
> allocated internal buffer on the PCI card.
>
> I/O Interface Port A
> I/O Interface Port B
> I/O Interface Port C
> I/O Interface Port D
>> Are you talking about four function on same card or pci card with four
> i/o > registers?
>
> Unfortunately with the CreateFile operation you can not specify which
> I/O
> Interface you wish to use, unless you send a DeviceIoControl command
> down to
> the driver after it has opened to define which Interface the user wish
> to
> use.
>
> I need the facility to be able to read from more than one I/O interface,
> so
> my question is this… is it possible to perhaps load a device driver
> for
> each I/O interface on the PCI card, effectively having 4 instances of
> the
> driver so that it can allocate any resources necessary to handle
> subsequent
> I/O requests.
>
> It must be possible since I’ve seen PCI cards with combined USB,
> Ethernet
> and Firewire controllers built onto a single PCI card.
>>These cards have multiple functions.
>
> or is there another way to handle this?
>
>
>
>
>
>
>
> This email and any files attached are intended for the addressee and may
> contain information of a confidential nature. If you are not the
> intended
> recipient, be aware that this email was sent to you in error and you
> should
> not disclose, distribute, print, copy or make other use of this email or
> its
> attachments. Such actions, in fact, may be unlawful. In compliance
> with
> the various Regulations and Acts, General Dynamics UK Limited reserves
> the
> right to monitor (and examine for viruses) all emails and email
> attachments,
> both inbound and outbound. Email communications and their attachments
> may
> not be secure or error- or virus-free and the company does not accept
> liability or responsibility for such matters or the consequences
> thereof.
> Registered Office: 100 New Bridge Street, London EC4V 6JA. Registered
> in
> England and Wales No: 1911653.
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@wipro.com
> 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: unknown lmsubst tag argument:
> ‘’
> To unsubscribe send a blank email to xxxxx@lists.osr.com
> This email and any files attached are intended for the addressee and may
> contain information of a confidential nature. If you are not the
> intended
> recipient, be aware that this email was sent to you in error and you
> should
> not disclose, distribute, print, copy or make other use of this email or
> its
> attachments. Such actions, in fact, may be unlawful. In compliance
> with
> the various Regulations and Acts, General Dynamics UK Limited reserves
> the
> right to monitor (and examine for viruses) all emails and email
> attachments,
> both inbound and outbound. Email communications and their attachments
> may
> not be secure or error- or virus-free and the company does not accept
> liability or responsibility for such matters or the consequences
> thereof.
> Registered Office: 100 New Bridge Street, London EC4V 6JA. Registered
> in
> England and Wales No: 1911653.
>
> —
> 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
>
> —
> 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
> This email and any files attached are intended for the addressee and may
> contain information of a confidential nature. If you are not the intended
> recipient, be aware that this email was sent to you in error and you
> should
> not disclose, distribute, print, copy or make other use of this email or
> its
> attachments. Such actions, in fact, may be unlawful. In compliance with
> the various Regulations and Acts, General Dynamics UK Limited reserves the
> right to monitor (and examine for viruses) all emails and email
> attachments,
> both inbound and outbound. Email communications and their attachments may
> not be secure or error- or virus-free and the company does not accept
> liability or responsibility for such matters or the consequences thereof.
> Registered Office: 100 New Bridge Street, London EC4V 6JA. Registered in
> England and Wales No: 1911653.
>

9

I still fail to see how this technique will work if I wish to communicate to
both channels simultaneously. when handle the IRP_MJ_CREATE in the
DispatchCreateOpen routine the IRP will have no knowledge of the handle
which will be returned back to the user application, because it hasn’t been
created yet. So I fail to see how u can determine from the IRP_MJ_READ which
handle is associated with which channel, if more than one handle has been
opened on the device.

I know you can obtain the user thread context from which the call to
CreateFile was called from in the IRP, but it is not safe to assume that the
user thread context obtained from the IRP_MJ_CREATE will be the same as the
user thread context obtained from the IRP_MJ_READ, after all it could be a
multithreaded application.

James

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of
xxxxx@exgate.tek.com
Sent: 26 October 2005 14:45
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Multi Functional PCI Device Driver

I would also suggest the namespace variant. If you want to open channel1
and channel2 then it’s straightforward:
Open chanel1 and channel2, you get two handles. This is same as if you
created two devices…

Robin

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of James Dunning
Sent: Mittwoch, 26. Oktober 2005 15:33
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Multi Functional PCI Device Driver

Hi Mark,

I can see what you are trying to say, basically if I register a device
interface with a symbolic link with something along the lines of
\DosDevices\Foo, I can tag a string on the end of the \DosDevices\Foo
and
this would simply be passed down to IRP_MJ_CREATE, when the application
opens the device

so if my application opens \DosDevices\Foo\Channel1 my driver could
process
the string “Channel1” and configure that channel accordingly.

However here’s my problem. lets say I want to read from Channel 1 and
Channel 2 simultaneously. How would IRP_MJ_READ know whether the
requested
read operation was for the channel 1 or channel 2 interface? this is
why I
am wondering whether it would be easier to have 4 functional devices for
the
PCI card.

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

You are currently subscribed to ntdev as:
xxxxx@generaldynamics.uk.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
This email and any files attached are intended for the addressee and may
contain information of a confidential nature. If you are not the intended
recipient, be aware that this email was sent to you in error and you should
not disclose, distribute, print, copy or make other use of this email or its
attachments. Such actions, in fact, may be unlawful. In compliance with
the various Regulations and Acts, General Dynamics UK Limited reserves the
right to monitor (and examine for viruses) all emails and email attachments,
both inbound and outbound. Email communications and their attachments may
not be secure or error- or virus-free and the company does not accept
liability or responsibility for such matters or the consequences thereof.
Registered Office: 100 New Bridge Street, London EC4V 6JA. Registered in
England and Wales No: 1911653.

10

Take a look at the article
http://www.microsoft.com/whdc/Driver/tips/DevNamespace.mspx. Basically,
when you open your device you would tack on a channel identifier, the open
will create a file object which you can then use to identify that the
subsequest IRP’s are for a specific device.

–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Remove StopSpam from the email to reply

“James Dunning” wrote in message
news:xxxxx@ntdev…
>I still fail to see how this technique will work if I wish to communicate
>to
> both channels simultaneously. when handle the IRP_MJ_CREATE in the
> DispatchCreateOpen routine the IRP will have no knowledge of the handle
> which will be returned back to the user application, because it hasn’t
> been
> created yet. So I fail to see how u can determine from the IRP_MJ_READ
> which
> handle is associated with which channel, if more than one handle has been
> opened on the device.
>
> I know you can obtain the user thread context from which the call to
> CreateFile was called from in the IRP, but it is not safe to assume that
> the
> user thread context obtained from the IRP_MJ_CREATE will be the same as
> the
> user thread context obtained from the IRP_MJ_READ, after all it could be a
> multithreaded application.
>
> James
>
>
>
>
>
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com]On Behalf Of
> xxxxx@exgate.tek.com
> Sent: 26 October 2005 14:45
> To: Windows System Software Devs Interest List
> Subject: RE: [ntdev] Multi Functional PCI Device Driver
>
>
> I would also suggest the namespace variant. If you want to open channel1
> and channel2 then it’s straightforward:
> Open chanel1 and channel2, you get two handles. This is same as if you
> created two devices…
>
> Robin
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of James Dunning
> Sent: Mittwoch, 26. Oktober 2005 15:33
> To: Windows System Software Devs Interest List
> Subject: RE: [ntdev] Multi Functional PCI Device Driver
>
>
> Hi Mark,
>
> I can see what you are trying to say, basically if I register a device
> interface with a symbolic link with something along the lines of
> \DosDevices\Foo, I can tag a string on the end of the \DosDevices\Foo
> and
> this would simply be passed down to IRP_MJ_CREATE, when the application
> opens the device
>
> so if my application opens \DosDevices\Foo\Channel1 my driver could
> process
> the string “Channel1” and configure that channel accordingly.
>
> However here’s my problem. lets say I want to read from Channel 1 and
> Channel 2 simultaneously. How would IRP_MJ_READ know whether the
> requested
> read operation was for the channel 1 or channel 2 interface? this is
> why I
> am wondering whether it would be easier to have 4 functional devices for
> the
> PCI card.
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as:
> xxxxx@generaldynamics.uk.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
> This email and any files attached are intended for the addressee and may
> contain information of a confidential nature. If you are not the intended
> recipient, be aware that this email was sent to you in error and you
> should
> not disclose, distribute, print, copy or make other use of this email or
> its
> attachments. Such actions, in fact, may be unlawful. In compliance with
> the various Regulations and Acts, General Dynamics UK Limited reserves the
> right to monitor (and examine for viruses) all emails and email
> attachments,
> both inbound and outbound. Email communications and their attachments may
> not be secure or error- or virus-free and the company does not accept
> liability or responsibility for such matters or the consequences thereof.
> Registered Office: 100 New Bridge Street, London EC4V 6JA. Registered in
> England and Wales No: 1911653.
>

11

Ah ha, ok I see how this approach would work, I didn’t realise you could
create an internal
structure which could be saved to the FILE_OBJECT when processing the
IRP_MJ_CREATE dispatch routine, that can be later extracted from every other
dispatch routine.

Cheers.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of
xxxxx@exgate.tek.com
Sent: 26 October 2005 14:45
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Multi Functional PCI Device Driver

I would also suggest the namespace variant. If you want to open channel1
and channel2 then it’s straightforward:
Open chanel1 and channel2, you get two handles. This is same as if you
created two devices…

Robin

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of James Dunning
Sent: Mittwoch, 26. Oktober 2005 15:33
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Multi Functional PCI Device Driver

Hi Mark,

I can see what you are trying to say, basically if I register a device
interface with a symbolic link with something along the lines of
\DosDevices\Foo, I can tag a string on the end of the \DosDevices\Foo
and
this would simply be passed down to IRP_MJ_CREATE, when the application
opens the device

so if my application opens \DosDevices\Foo\Channel1 my driver could
process
the string “Channel1” and configure that channel accordingly.

However here’s my problem. lets say I want to read from Channel 1 and
Channel 2 simultaneously. How would IRP_MJ_READ know whether the
requested
read operation was for the channel 1 or channel 2 interface? this is
why I
am wondering whether it would be easier to have 4 functional devices for
the
PCI card.

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

You are currently subscribed to ntdev as:
xxxxx@generaldynamics.uk.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
This email and any files attached are intended for the addressee and may
contain information of a confidential nature. If you are not the intended
recipient, be aware that this email was sent to you in error and you should
not disclose, distribute, print, copy or make other use of this email or its
attachments. Such actions, in fact, may be unlawful. In compliance with
the various Regulations and Acts, General Dynamics UK Limited reserves the
right to monitor (and examine for viruses) all emails and email attachments,
both inbound and outbound. Email communications and their attachments may
not be secure or error- or virus-free and the company does not accept
liability or responsibility for such matters or the consequences thereof.
Registered Office: 100 New Bridge Street, London EC4V 6JA. Registered in
England and Wales No: 1911653.

12

Assuming that you’re not wedging yourself into an existing stack where they
are already taken, FileObject->FsContext and FileObject->FsContext2 are fair
game for whatever you want to put in there.

-scott

–
Scott Noone
Software Engineer
OSR Open Systems Resources, Inc.
http://www.osronline.com

“James Dunning” wrote in message
news:xxxxx@ntdev…
> Ah ha, ok I see how this approach would work, I didn’t realise you could
> create an internal
> structure which could be saved to the FILE_OBJECT when processing the
> IRP_MJ_CREATE dispatch routine, that can be later extracted from every
> other
> dispatch routine.
>
> Cheers.
>
>
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com]On Behalf Of
> xxxxx@exgate.tek.com
> Sent: 26 October 2005 14:45
> To: Windows System Software Devs Interest List
> Subject: RE: [ntdev] Multi Functional PCI Device Driver
>
>
> I would also suggest the namespace variant. If you want to open channel1
> and channel2 then it’s straightforward:
> Open chanel1 and channel2, you get two handles. This is same as if you
> created two devices…
>
> Robin
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of James Dunning
> Sent: Mittwoch, 26. Oktober 2005 15:33
> To: Windows System Software Devs Interest List
> Subject: RE: [ntdev] Multi Functional PCI Device Driver
>
>
> Hi Mark,
>
> I can see what you are trying to say, basically if I register a device
> interface with a symbolic link with something along the lines of
> \DosDevices\Foo, I can tag a string on the end of the \DosDevices\Foo
> and
> this would simply be passed down to IRP_MJ_CREATE, when the application
> opens the device
>
> so if my application opens \DosDevices\Foo\Channel1 my driver could
> process
> the string “Channel1” and configure that channel accordingly.
>
> However here’s my problem. lets say I want to read from Channel 1 and
> Channel 2 simultaneously. How would IRP_MJ_READ know whether the
> requested
> read operation was for the channel 1 or channel 2 interface? this is
> why I
> am wondering whether it would be easier to have 4 functional devices for
> the
> PCI card.
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as:
> xxxxx@generaldynamics.uk.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
> This email and any files attached are intended for the addressee and may
> contain information of a confidential nature. If you are not the intended
> recipient, be aware that this email was sent to you in error and you
> should
> not disclose, distribute, print, copy or make other use of this email or
> its
> attachments. Such actions, in fact, may be unlawful. In compliance with
> the various Regulations and Acts, General Dynamics UK Limited reserves the
> right to monitor (and examine for viruses) all emails and email
> attachments,
> both inbound and outbound. Email communications and their attachments may
> not be secure or error- or virus-free and the company does not accept
> liability or responsibility for such matters or the consequences thereof.
> Registered Office: 100 New Bridge Street, London EC4V 6JA. Registered in
> England and Wales No: 1911653.
>

13

Here’s a piece of code I used for crate/close:
The name used can be found in the fileobject. You just save the
fileobject for further refernces.
I think there was an article either on OSR or Walter Oneys WD3 site
somwhere, but I can’t seem to find it anymore.

NTSTATUS MydevCreate(PDEVICE_OBJECT fdo, PIRP Irp) {
PIO_STACK_LOCATION ioStack = IoGetCurrentIrpStackLocation(Irp);
PFILE_OBJECT f = ioStack->FileObject;
TraceEvents(TRACE_LEVEL_INFORMATION, DBG_CREATE_CLOSE,
DRIVERNAME “CreateFile called with filename %ws\n”, f->FileName.Buffer);

// handle the open with this NAME!
…
}

NTSTATUS MydevClose(PDEVICE_OBJECT fdo, PIRP Irp) {
PIO_STACK_LOCATION ioStack = IoGetCurrentIrpStackLocation(Irp);
PFILE_OBJECT f = ioStack->FileObject;

TraceEvents(TRACE_LEVEL_INFORMATION, DBG_CREATE_CLOSE,
DRIVERNAME “CloseFile called with filename %ws\n”, f->FileName.Buffer);

// Handle close with this object or NAME
…
}

Cheers
Robin

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of James Dunning
Sent: Mittwoch, 26. Oktober 2005 17:06
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Multi Functional PCI Device Driver

I still fail to see how this technique will work if I wish to
communicate to
both channels simultaneously. when handle the IRP_MJ_CREATE in the
DispatchCreateOpen routine the IRP will have no knowledge of the handle
which will be returned back to the user application, because it hasn’t
been
created yet. So I fail to see how u can determine from the IRP_MJ_READ
which
handle is associated with which channel, if more than one handle has
been
opened on the device.

I know you can obtain the user thread context from which the call to
CreateFile was called from in the IRP, but it is not safe to assume that
the
user thread context obtained from the IRP_MJ_CREATE will be the same as
the
user thread context obtained from the IRP_MJ_READ, after all it could be
a
multithreaded application.

James

14

Ahhh… Here is the article I meant (BTW, what’s with that web site,
nothing new since quite some time now)
http://www.wd-3.com/archive/namespace.htm

Robin
-----Original Message-----
From: Mitra, Robin
Sent: Mittwoch, 26. Oktober 2005 17:47
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Multi Functional PCI Device Driver

Here’s a piece of code I used for crate/close:
The name used can be found in the fileobject. You just save the
fileobject for further refernces.
I think there was an article either on OSR or Walter Oneys WD3 site
somwhere, but I can’t seem to find it anymore.

NTSTATUS MydevCreate(PDEVICE_OBJECT fdo, PIRP Irp) {
PIO_STACK_LOCATION ioStack = IoGetCurrentIrpStackLocation(Irp);
PFILE_OBJECT f = ioStack->FileObject;
TraceEvents(TRACE_LEVEL_INFORMATION, DBG_CREATE_CLOSE,
DRIVERNAME “CreateFile called with filename %ws\n”, f->FileName.Buffer);

// handle the open with this NAME!
…
}

NTSTATUS MydevClose(PDEVICE_OBJECT fdo, PIRP Irp) {
PIO_STACK_LOCATION ioStack = IoGetCurrentIrpStackLocation(Irp);
PFILE_OBJECT f = ioStack->FileObject;

TraceEvents(TRACE_LEVEL_INFORMATION, DBG_CREATE_CLOSE,
DRIVERNAME “CloseFile called with filename %ws\n”, f->FileName.Buffer);

// Handle close with this object or NAME
…
}

Cheers
Robin

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of James Dunning
Sent: Mittwoch, 26. Oktober 2005 17:06
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Multi Functional PCI Device Driver

I still fail to see how this technique will work if I wish to
communicate to
both channels simultaneously. when handle the IRP_MJ_CREATE in the
DispatchCreateOpen routine the IRP will have no knowledge of the handle
which will be returned back to the user application, because it hasn’t
been
created yet. So I fail to see how u can determine from the IRP_MJ_READ
which
handle is associated with which channel, if more than one handle has
been
opened on the device.

I know you can obtain the user thread context from which the call to
CreateFile was called from in the IRP, but it is not safe to assume that
the
user thread context obtained from the IRP_MJ_CREATE will be the same as
the
user thread context obtained from the IRP_MJ_READ, after all it could be
a
multithreaded application.

James

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

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

15

Each separate create gets its own file object. Each IRP will point to
the file object it was issued through (including the create, cleanup and
close messages).

During create you can allocate a file object extension and store a
pointer to this in the FileObject->FsContext pointer. You store in
there some information about which interface the caller opened.

During an I/O operation you look at this structure to figure out which
interface it’s targetted at.

During cleanup you cancel all the outstanding I/O operations on that
file.

During close you free the file object extension (after you’ve gotten rid
of all the dangling pointers to it, etc…)

If two calls are made to open \.\Device\Foo\Interface0 then each will
get its own file object. If you want to provide exclusive access to a
particular interface you can keep some “open counts” (one for each
interface) in your device extension.

-p

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of James Dunning
Sent: Wednesday, October 26, 2005 8:06 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Multi Functional PCI Device Driver

I still fail to see how this technique will work if I wish to
communicate to both channels simultaneously. when handle the
IRP_MJ_CREATE in the DispatchCreateOpen routine the IRP will have no
knowledge of the handle which will be returned back to the user
application, because it hasn’t been created yet. So I fail to see how u
can determine from the IRP_MJ_READ which handle is associated with which
channel, if more than one handle has been opened on the device.

I know you can obtain the user thread context from which the call to
CreateFile was called from in the IRP, but it is not safe to assume that
the user thread context obtained from the IRP_MJ_CREATE will be the same
as the user thread context obtained from the IRP_MJ_READ, after all it
could be a multithreaded application.

James

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of
xxxxx@exgate.tek.com
Sent: 26 October 2005 14:45
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Multi Functional PCI Device Driver

I would also suggest the namespace variant. If you want to open channel1
and channel2 then it’s straightforward:
Open chanel1 and channel2, you get two handles. This is same as if you
created two devices…

Robin

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of James Dunning
Sent: Mittwoch, 26. Oktober 2005 15:33
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Multi Functional PCI Device Driver

Hi Mark,

I can see what you are trying to say, basically if I register a device
interface with a symbolic link with something along the lines of
\DosDevices\Foo, I can tag a string on the end of the \DosDevices\Foo
and this would simply be passed down to IRP_MJ_CREATE, when the
application opens the device

so if my application opens \DosDevices\Foo\Channel1 my driver could
process the string “Channel1” and configure that channel accordingly.

However here’s my problem. lets say I want to read from Channel 1 and
Channel 2 simultaneously. How would IRP_MJ_READ know whether the
requested read operation was for the channel 1 or channel 2 interface?
this is why I am wondering whether it would be easier to have 4
functional devices for the PCI card.

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

You are currently subscribed to ntdev as:
xxxxx@generaldynamics.uk.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
This email and any files attached are intended for the addressee and may
contain information of a confidential nature. If you are not the
intended recipient, be aware that this email was sent to you in error
and you should not disclose, distribute, print, copy or make other use
of this email or its attachments. Such actions, in fact, may be
unlawful. In compliance with the various Regulations and Acts, General
Dynamics UK Limited reserves the right to monitor (and examine for
viruses) all emails and email attachments, both inbound and outbound.
Email communications and their attachments may not be secure or error-
or virus-free and the company does not accept liability or
responsibility for such matters or the consequences thereof.
Registered Office: 100 New Bridge Street, London EC4V 6JA. Registered
in England and Wales No: 1911653.

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

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

16

> I still fail to see how this technique will work if I wish to communicate to

both channels simultaneously.

Add one more reference string kind of \IoChannels0And1 or such.

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

17

Yes, set FileObject->FsContext2 to point to your structure.

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

----- Original Message -----
From: “James Dunning”
To: “Windows System Software Devs Interest List”
Sent: Wednesday, October 26, 2005 7:15 PM
Subject: RE: [ntdev] Multi Functional PCI Device Driver

> Ah ha, ok I see how this approach would work, I didn’t realise you could
> create an internal
> structure which could be saved to the FILE_OBJECT when processing the
> IRP_MJ_CREATE dispatch routine, that can be later extracted from every other
> dispatch routine.
>
> Cheers.
>
>
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com]On Behalf Of
> xxxxx@exgate.tek.com
> Sent: 26 October 2005 14:45
> To: Windows System Software Devs Interest List
> Subject: RE: [ntdev] Multi Functional PCI Device Driver
>
>
> I would also suggest the namespace variant. If you want to open channel1
> and channel2 then it’s straightforward:
> Open chanel1 and channel2, you get two handles. This is same as if you
> created two devices…
>
> Robin
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of James Dunning
> Sent: Mittwoch, 26. Oktober 2005 15:33
> To: Windows System Software Devs Interest List
> Subject: RE: [ntdev] Multi Functional PCI Device Driver
>
>
> Hi Mark,
>
> I can see what you are trying to say, basically if I register a device
> interface with a symbolic link with something along the lines of
> \DosDevices\Foo, I can tag a string on the end of the \DosDevices\Foo
> and
> this would simply be passed down to IRP_MJ_CREATE, when the application
> opens the device
>
> so if my application opens \DosDevices\Foo\Channel1 my driver could
> process
> the string “Channel1” and configure that channel accordingly.
>
> However here’s my problem. lets say I want to read from Channel 1 and
> Channel 2 simultaneously. How would IRP_MJ_READ know whether the
> requested
> read operation was for the channel 1 or channel 2 interface? this is
> why I
> am wondering whether it would be easier to have 4 functional devices for
> the
> PCI card.
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as:
> xxxxx@generaldynamics.uk.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
> This email and any files attached are intended for the addressee and may
> contain information of a confidential nature. If you are not the intended
> recipient, be aware that this email was sent to you in error and you should
> not disclose, distribute, print, copy or make other use of this email or its
> attachments. Such actions, in fact, may be unlawful. In compliance with
> the various Regulations and Acts, General Dynamics UK Limited reserves the
> right to monitor (and examine for viruses) all emails and email attachments,
> both inbound and outbound. Email communications and their attachments may
> not be secure or error- or virus-free and the company does not accept
> liability or responsibility for such matters or the consequences thereof.
> Registered Office: 100 New Bridge Street, London EC4V 6JA. Registered in
> England and Wales No: 1911653.
>
> —
> Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@storagecraft.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com

18

Create a GUID and register an interface for each interface and enumerate
them in your application using the SetupDiXxxx functions.

–
The personal opinion of
Gary G. Little

“James Dunning” wrote in message
news:xxxxx@ntdev…
>I am currently developing a PCI device driver, so far so good, since I am
> able to talk to the PCI device. however I have come across a design
> issue.
>
> This PCI Device has four I/O interfaces, each interface has its own
> allocated internal buffer on the PCI card.
>
> I/O Interface Port A
> I/O Interface Port B
> I/O Interface Port C
> I/O Interface Port D
>
> Unfortunately with the CreateFile operation you can not specify which I/O
> Interface you wish to use, unless you send a DeviceIoControl command down
> to
> the driver after it has opened to define which Interface the user wish to
> use.
>
> I need the facility to be able to read from more than one I/O interface,
> so
> my question is this… is it possible to perhaps load a device driver for
> each I/O interface on the PCI card, effectively having 4 instances of the
> driver so that it can allocate any resources necessary to handle
> subsequent
> I/O requests.
>
> It must be possible since I’ve seen PCI cards with combined USB, Ethernet
> and Firewire controllers built onto a single PCI card.
>
> or is there another way to handle this?
>
>
>
>
>
>
>
> This email and any files attached are intended for the addressee and may
> contain information of a confidential nature. If you are not the intended
> recipient, be aware that this email was sent to you in error and you
> should
> not disclose, distribute, print, copy or make other use of this email or
> its
> attachments. Such actions, in fact, may be unlawful. In compliance with
> the various Regulations and Acts, General Dynamics UK Limited reserves the
> right to monitor (and examine for viruses) all emails and email
> attachments,
> both inbound and outbound. Email communications and their attachments may
> not be secure or error- or virus-free and the company does not accept
> liability or responsibility for such matters or the consequences thereof.
> Registered Office: 100 New Bridge Street, London EC4V 6JA. Registered in
> England and Wales No: 1911653.
>

19

Walter stopped beating us severely and in response we stopped submitting
new articles.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@exgate.tek.com
Sent: Wednesday, October 26, 2005 1:20 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Multi Functional PCI Device Driver

Ahhh… Here is the article I meant (BTW, what’s with that web site,
nothing new since quite some time now)
http://www.wd-3.com/archive/namespace.htm

Robin
-----Original Message-----
From: Mitra, Robin
Sent: Mittwoch, 26. Oktober 2005 17:47
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Multi Functional PCI Device Driver

Here’s a piece of code I used for crate/close:
The name used can be found in the fileobject. You just save the
fileobject for further refernces.
I think there was an article either on OSR or Walter Oneys WD3 site
somwhere, but I can’t seem to find it anymore.

NTSTATUS MydevCreate(PDEVICE_OBJECT fdo, PIRP Irp) {
PIO_STACK_LOCATION ioStack = IoGetCurrentIrpStackLocation(Irp);
PFILE_OBJECT f = ioStack->FileObject;
TraceEvents(TRACE_LEVEL_INFORMATION, DBG_CREATE_CLOSE,
DRIVERNAME “CreateFile called with filename %ws\n”, f->FileName.Buffer);

// handle the open with this NAME!
…
}

NTSTATUS MydevClose(PDEVICE_OBJECT fdo, PIRP Irp) {
PIO_STACK_LOCATION ioStack = IoGetCurrentIrpStackLocation(Irp);
PFILE_OBJECT f = ioStack->FileObject;

TraceEvents(TRACE_LEVEL_INFORMATION, DBG_CREATE_CLOSE,
DRIVERNAME “CloseFile called with filename %ws\n”, f->FileName.Buffer);

// Handle close with this object or NAME
…
}

Cheers
Robin

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of James Dunning
Sent: Mittwoch, 26. Oktober 2005 17:06
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Multi Functional PCI Device Driver

I still fail to see how this technique will work if I wish to
communicate to
both channels simultaneously. when handle the IRP_MJ_CREATE in the
DispatchCreateOpen routine the IRP will have no knowledge of the handle
which will be returned back to the user application, because it hasn’t
been
created yet. So I fail to see how u can determine from the IRP_MJ_READ
which
handle is associated with which channel, if more than one handle has
been
opened on the device.

I know you can obtain the user thread context from which the call to
CreateFile was called from in the IRP, but it is not safe to assume that
the
user thread context obtained from the IRP_MJ_CREATE will be the same as
the
user thread context obtained from the IRP_MJ_READ, after all it could be
a
multithreaded application.

James

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

You are currently subscribed to ntdev as: xxxxx@exgate.tek.com
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

20

Cheers guys, I also found the article at
http://www.wd-3.com/archive/namespace.htm
very helpful! I didn’t realise you could store objects in
FileObject->FsContext,

by the way, this email server seems to be seriously lagged, my last email
took over
6 hours to be delivered!

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Roddy, Mark
Sent: 26 October 2005 18:52
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Multi Functional PCI Device Driver

Walter stopped beating us severely and in response we stopped submitting
new articles.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@exgate.tek.com
Sent: Wednesday, October 26, 2005 1:20 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Multi Functional PCI Device Driver

Ahhh… Here is the article I meant (BTW, what’s with that web site,
nothing new since quite some time now)
http://www.wd-3.com/archive/namespace.htm

Robin
-----Original Message-----
From: Mitra, Robin
Sent: Mittwoch, 26. Oktober 2005 17:47
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Multi Functional PCI Device Driver

Here’s a piece of code I used for crate/close:
The name used can be found in the fileobject. You just save the
fileobject for further refernces.
I think there was an article either on OSR or Walter Oneys WD3 site
somwhere, but I can’t seem to find it anymore.

NTSTATUS MydevCreate(PDEVICE_OBJECT fdo, PIRP Irp) {
PIO_STACK_LOCATION ioStack = IoGetCurrentIrpStackLocation(Irp);
PFILE_OBJECT f = ioStack->FileObject;
TraceEvents(TRACE_LEVEL_INFORMATION, DBG_CREATE_CLOSE,
DRIVERNAME “CreateFile called with filename %ws\n”, f->FileName.Buffer);

// handle the open with this NAME!
…
}

NTSTATUS MydevClose(PDEVICE_OBJECT fdo, PIRP Irp) {
PIO_STACK_LOCATION ioStack = IoGetCurrentIrpStackLocation(Irp);
PFILE_OBJECT f = ioStack->FileObject;

TraceEvents(TRACE_LEVEL_INFORMATION, DBG_CREATE_CLOSE,
DRIVERNAME “CloseFile called with filename %ws\n”, f->FileName.Buffer);

// Handle close with this object or NAME
…
}

Cheers
Robin

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of James Dunning
Sent: Mittwoch, 26. Oktober 2005 17:06
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Multi Functional PCI Device Driver

I still fail to see how this technique will work if I wish to
communicate to
both channels simultaneously. when handle the IRP_MJ_CREATE in the
DispatchCreateOpen routine the IRP will have no knowledge of the handle
which will be returned back to the user application, because it hasn’t
been
created yet. So I fail to see how u can determine from the IRP_MJ_READ
which
handle is associated with which channel, if more than one handle has
been
opened on the device.

I know you can obtain the user thread context from which the call to
CreateFile was called from in the IRP, but it is not safe to assume that
the
user thread context obtained from the IRP_MJ_CREATE will be the same as
the
user thread context obtained from the IRP_MJ_READ, after all it could be
a
multithreaded application.

James

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

You are currently subscribed to ntdev as: xxxxx@exgate.tek.com
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

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
This email and any files attached are intended for the addressee and may
contain information of a confidential nature. If you are not the intended
recipient, be aware that this email was sent to you in error and you should
not disclose, distribute, print, copy or make other use of this email or its
attachments. Such actions, in fact, may be unlawful. In compliance with
the various Regulations and Acts, General Dynamics UK Limited reserves the
right to monitor (and examine for viruses) all emails and email attachments,
both inbound and outbound. Email communications and their attachments may
not be secure or error- or virus-free and the company does not accept
liability or responsibility for such matters or the consequences thereof.
Registered Office: 100 New Bridge Street, London EC4V 6JA. Registered in
England and Wales No: 1911653.