Help with Multi-channel PCI Serial I/O driver in KMDF

NTDEV
1

Does anybody have any KMDF sample code or expertise that might be of use for
porting a multi-channel PCI serial I/O card from an old pre-WDM (NT) driver
to KMDF?
I’m having a bit of trouble trying to figure out how to separate out the
processing of the card’s multiple channels with respect to the common card
resources (DMA, Interrupt, Memory/Register mapping etc.) using FDOs, PDOs.
I’m not even sure if I should be using a PDO for each channel and a single
FDO for the common stuff.

Any help in the area of how KMDF should deal with PCI cards with multiple
independent serial I/O channels in the new KMDF Framework would be much
appreciated.

Bill Simpson
xxxxx@braxtontech.com
Braxton Technologies, Inc.
www.braxtontech.com

2

PCI samples: src\kmdf\PLX9x5x, src\kmdf\pcidrv
Serial: kmdf\serial
As for how to set things up, do you want to expose a separate COM port for each of your channels? If yes, then you must enumerate a PDO for COM port you want to expose. If no, how are the multiple channels addressed by the application?
Assuming you need PDOs for each COM port, you would keep all the resoures in the FDO. You can then choose to fwd all requests to the FDO and process each there or have a private channel between the PDO and FDO (it is the same driver,so this is easy) to “acquire” the appropriate resources for each channel.
d

From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Bill Simpson
Sent: Saturday, September 15, 2007 3:09 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Help with Multi-channel PCI Serial I/O driver in KMDF

Does anybody have any KMDF sample code or expertise that might be of use for porting a multi-channel PCI serial I/O card from an old pre-WDM (NT) driver to KMDF?
I’m having a bit of trouble trying to figure out how to separate out the processing of the card’s multiple channels with respect to the common card resources (DMA, Interrupt, Memory/Register mapping etc.) using FDOs, PDOs. I’m not even sure if I should be using a PDO for each channel and a single FDO for the common stuff.
Any help in the area of how KMDF should deal with PCI cards with multiple independent serial I/O channels in the new KMDF Framework would be much appreciated.

Bill Simpson
xxxxx@braxtontech.com
Braxton Technologies, Inc.
www.braxtontech.com

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

3

d,

I’m using a derivative of the PCIDRV source for my prototyping (with
significant deltas). The ‘Serial’ sample source was interesting but didn’t
seem to deal with the concept of simultaneous streams of data so I didn’t
pursue it too far. I’ll relook at it now that you bring it up.

The serial I/O I’m targeting is low/medium rate GPS telemetry data (we
launch the GPS satellites for the USAF).
I’m NOT mapping the I/O to the standard COM ports, I’m doing a separate
CreateFile(.) for each channel (the way we use to do in NT drivers). Each
channel can have independent Win32 threads transmitting and receiving
continuous (streaming) telemetry (State of Health) data to/from the GPS
vehicles (the data is synchronous RS-422 data & clock).

What you say toward the end of your last email gives me hope that my theory
of needing a PDO for each channel makes sense. My only worry is that there
seems to be so much more ‘Stuff’ between the DMA transfer I’m use to doing
(in my old NT driver code) and the new KMDF. I needed to squeeze all the
I/O power out of the old NT systems to get the data processed properly. The
idea of having all these FDO/PDO layers worries me re performance.

If I’m required to make a PDO for each channel are you saying that I need to
vector all my IOCTL messages through a single Interface GUID then have the
FDO forward these messages to the channels (PDOs)? That seems like a
bottleneck to me but if that’s the standard then I guess I can give it a
try.

I’ve got to say that in the old NT device driver days the concept of
multi-channel cards was very common - when I look at the latest sample code,
they (MS) actually state that they DON’T cover multi-function
(multi-channel) device drivers in the sample code. What’s up with that?
In my world there are more and more smart/not-so-smart I/O cards that have
2,4,8,16,32 channels that need to have high independent throughput. Drivers
for these puppies will need to be written if we are going to get away from
VXWorks.

bill

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
Sent: Saturday, September 15, 2007 5:07 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Help with Multi-channel PCI Serial I/O driver in KMDF

PCI samples: src\kmdf\PLX9x5x, src\kmdf\pcidrv

Serial: kmdf\serial

As for how to set things up, do you want to expose a separate COM port for
each of your channels? If yes, then you must enumerate a PDO for COM port
you want to expose. If no, how are the multiple channels addressed by the
application?

Assuming you need PDOs for each COM port, you would keep all the resoures in
the FDO. You can then choose to fwd all requests to the FDO and process
each there or have a private channel between the PDO and FDO (it is the same
driver,so this is easy) to “acquire” the appropriate resources for each
channel.

d

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Bill Simpson
Sent: Saturday, September 15, 2007 3:09 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Help with Multi-channel PCI Serial I/O driver in KMDF

Does anybody have any KMDF sample code or expertise that might be of use for
porting a multi-channel PCI serial I/O card from an old pre-WDM (NT) driver
to KMDF?
I’m having a bit of trouble trying to figure out how to separate out the
processing of the card’s multiple channels with respect to the common card
resources (DMA, Interrupt, Memory/Register mapping etc.) using FDOs, PDOs.
I’m not even sure if I should be using a PDO for each channel and a single
FDO for the common stuff.

Any help in the area of how KMDF should deal with PCI cards with multiple
independent serial I/O channels in the new KMDF Framework would be much
appreciated.

Bill Simpson
xxxxx@braxtontech.com
Braxton Technologies, Inc.
www.braxtontech.com

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

4

In no particular order:

  1. The samples have changed over the years, with a greater focus on samples
    for hardware that you (and we) might actually be able to play with.
    Furthermore, ten years ago (in the NT time frame) we at Microsoft wrote a
    relatively large percentage of the device drivers so we owned the code.
    These days, if you have a multi-port serial device, it’s very likely that we
    didn’t write the driver for that and thus we don’t own the code to give you.
    For a while, we just tried to write “samples” that showed the general
    concepts, but this code was never executed or tested and it often wasn’t
    satisfactory. Today’s samples are (mostly) tested and so they are of higher
    value. The problem is that limits them to more generic hardware. Does this
    answer your “what’s up with that” question?

  2. You don’t need a PDO for each channel. Doron couldn’t tell from your
    response whether you were trying to write driver that exposed COM ports
    generically. Your’e not. So you get to pick the interfaces that you
    expose. You could just open multiple handles to the same device and
    differentiate them somehow. You could append strings to the file name that
    you open and parse this part of the namespace in your driver. Or you could
    just assume that the first opened handle should be associated with a
    particular resource, the second another, etc., though this is a fairly
    fragile paradigm. Or you could open a handle and then send an IOCTL on that
    handle saying that you want to associate this particular handle with a
    particular interface. Or you could create multiple control device objects,
    each with a separate name. You choose. It’s your code and your
    application. I can’t tell you what’s best without taking a much more
    detailed look at your needs.

  3. Similarly, I don’t think that the serial sample is going to do much for
    you. That mostly shows you how to expose a “COM” port to the OS.

  4. You’ve got the whole PDO/FDO thing backwards below. If you decide to
    create PDOs, they become your upper-edge interfaces. You’d receive requests
    on them which would then be forwarded to the FDO, not the other way around.

  5. Lastly, none of these choices have much impact on performance. You’ll do
    a little better with fewer layers in your code, but the real bottlenecks
    have to do with running data through the processor, or sending and receiving
    many IRPs, etc. If you’re doing DMA and you’re designing your
    read/write/IOCTL interfaces well, the choices that we’re discussing won’t
    have much impact.

  • Jake Oshins

“Bill Simpson” wrote in message
news:xxxxx@ntdev…
d,
I’m using a derivative of the PCIDRV source for my prototyping (with
significant deltas). The ‘Serial’ sample source was interesting but didn’t
seem to deal with the concept of simultaneous streams of data so I didn’t
pursue it too far. I’ll relook at it now that you bring it up.
The serial I/O I’m targeting is low/medium rate GPS telemetry data (we
launch the GPS satellites for the USAF).
I’m NOT mapping the I/O to the standard COM ports, I’m doing a separate
CreateFile(.) for each channel (the way we use to do in NT drivers). Each
channel can have independent Win32 threads transmitting and receiving
continuous (streaming) telemetry (State of Health) data to/from the GPS
vehicles (the data is synchronous RS-422 data & clock).
What you say toward the end of your last email gives me hope that my theory
of needing a PDO for each channel makes sense. My only worry is that there
seems to be so much more ‘Stuff’ between the DMA transfer I’m use to doing
(in my old NT driver code) and the new KMDF. I needed to squeeze all the
I/O power out of the old NT systems to get the data processed properly. The
idea of having all these FDO/PDO layers worries me re performance.
If I’m required to make a PDO for each channel are you saying that I need to
vector all my IOCTL messages through a single Interface GUID then have the
FDO forward these messages to the channels (PDOs)? That seems like a
bottleneck to me but if that’s the standard then I guess I can give it a
try.
I’ve got to say that in the old NT device driver days the concept of
multi-channel cards was very common - when I look at the latest sample code,
they (MS) actually state that they DON’T cover multi-function
(multi-channel) device drivers in the sample code. What’s up with that?
In my world there are more and more smart/not-so-smart I/O cards that have
2,4,8,16,32 channels that need to have high independent throughput. Drivers
for these puppies will need to be written if we are going to get away from
VXWorks.
bill

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
Sent: Saturday, September 15, 2007 5:07 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Help with Multi-channel PCI Serial I/O driver in KMDF

PCI samples: src\kmdf\PLX9x5x, src\kmdf\pcidrv
Serial: kmdf\serial
As for how to set things up, do you want to expose a separate COM port for
each of your channels? If yes, then you must enumerate a PDO for COM port
you want to expose. If no, how are the multiple channels addressed by the
application?
Assuming you need PDOs for each COM port, you would keep all the resoures in
the FDO. You can then choose to fwd all requests to the FDO and process
each there or have a private channel between the PDO and FDO (it is the same
driver,so this is easy) to “acquire” the appropriate resources for each
channel.
d

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Bill Simpson
Sent: Saturday, September 15, 2007 3:09 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Help with Multi-channel PCI Serial I/O driver in KMDF

Does anybody have any KMDF sample code or expertise that might be of use for
porting a multi-channel PCI serial I/O card from an old pre-WDM (NT) driver
to KMDF?
I’m having a bit of trouble trying to figure out how to separate out the
processing of the card’s multiple channels with respect to the common card
resources (DMA, Interrupt, Memory/Register mapping etc.) using FDOs, PDOs.
I’m not even sure if I should be using a PDO for each channel and a single
FDO for the common stuff.
Any help in the area of how KMDF should deal with PCI cards with multiple
independent serial I/O channels in the new KMDF Framework would be much
appreciated.

Bill Simpson
xxxxx@braxtontech.com
Braxton Technologies, Inc.
www.braxtontech.com

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

5

I will let Doron handle most of this, but multi-function is not multi-channel. The Serial driver works with one or more standard serial ports. Multi-function is such as a keyboard on the HID stack and sticking a hard drive in the keyboard. I know there are drivers that can handle multiple functions, but I think the device unique driver must create PDOs for standard devices so the function drivers can load and attach to them. I think you write a bus driver for those multi-function devices. KMDF has made that much easier than just using the standard NT kernel interfaces or WDM.

“Bill Simpson” wrote in message news:xxxxx@ntdev…
d,

I’m using a derivative of the PCIDRV source for my prototyping (with significant deltas). The ‘Serial’ sample source was interesting but didn’t seem to deal with the concept of simultaneous streams of data so I didn’t pursue it too far. I’ll relook at it now that you bring it up.

The serial I/O I’m targeting is low/medium rate GPS telemetry data (we launch the GPS satellites for the USAF).
I’m NOT mapping the I/O to the standard COM ports, I’m doing a separate CreateFile(.) for each channel (the way we use to do in NT drivers). Each channel can have independent Win32 threads transmitting and receiving continuous (streaming) telemetry (State of Health) data to/from the GPS vehicles (the data is synchronous RS-422 data & clock).

What you say toward the end of your last email gives me hope that my theory of needing a PDO for each channel makes sense. My only worry is that there seems to be so much more ‘Stuff’ between the DMA transfer I’m use to doing (in my old NT driver code) and the new KMDF. I needed to squeeze all the I/O power out of the old NT systems to get the data processed properly. The idea of having all these FDO/PDO layers worries me re performance.

If I’m required to make a PDO for each channel are you saying that I need to vector all my IOCTL messages through a single Interface GUID then have the FDO forward these messages to the channels (PDOs)? That seems like a bottleneck to me but if that’s the standard then I guess I can give it a try.

I’ve got to say that in the old NT device driver days the concept of multi-channel cards was very common - when I look at the latest sample code, they (MS) actually state that they DON’T cover multi-function (multi-channel) device drivers in the sample code. What’s up with that? In my world there are more and more smart/not-so-smart I/O cards that have 2,4,8,16,32 channels that need to have high independent throughput. Drivers for these puppies will need to be written if we are going to get away from VXWorks.

bill

From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
Sent: Saturday, September 15, 2007 5:07 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Help with Multi-channel PCI Serial I/O driver in KMDF

PCI samples: src\kmdf\PLX9x5x, src\kmdf\pcidrv

Serial: kmdf\serial

As for how to set things up, do you want to expose a separate COM port for each of your channels? If yes, then you must enumerate a PDO for COM port you want to expose. If no, how are the multiple channels addressed by the application?

Assuming you need PDOs for each COM port, you would keep all the resoures in the FDO. You can then choose to fwd all requests to the FDO and process each there or have a private channel between the PDO and FDO (it is the same driver,so this is easy) to “acquire” the appropriate resources for each channel.

d

From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Bill Simpson
Sent: Saturday, September 15, 2007 3:09 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Help with Multi-channel PCI Serial I/O driver in KMDF

Does anybody have any KMDF sample code or expertise that might be of use for porting a multi-channel PCI serial I/O card from an old pre-WDM (NT) driver to KMDF?
I’m having a bit of trouble trying to figure out how to separate out the processing of the card’s multiple channels with respect to the common card resources (DMA, Interrupt, Memory/Register mapping etc.) using FDOs, PDOs. I’m not even sure if I should be using a PDO for each channel and a single FDO for the common stuff.

Any help in the area of how KMDF should deal with PCI cards with multiple independent serial I/O channels in the new KMDF Framework would be much appreciated.

Bill Simpson
xxxxx@braxtontech.com
Braxton Technologies, Inc.
www.braxtontech.com

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

6

I allow multiple opens on each of my devices by maintaining a separate “per_open” structure for each user-side thread. This is a design I inherited from the previous driver, and it works real well. The serialization is handled by my chips through per-device hardware queues that can reside either in host memory or in board memory. Interrupts and Dma are done on a “per device” basis, the Open handle differentiates the streams.

I also do a lot of MP testing - my favorite testbed is the Dell 490, which has 4 hyperthreaded processors, that is, 8 effective processors. It’s really cool to turn on the Task Manager and watch all those performance windows going! I also do a lot of testing on PowerEdge servers because they come with four PCI Express slots, which lets me have multiple boards on the same machine.

I may be rowing against the party-line stream here, but my approach to these things is to minimize the amount of DDK calls in my code. I much prefer to drive the hardware myself, specially when I need performance! The way I would approach this project is this: I would separate the NT driver in two, an OS-dependent part and an OS-independent part. I would try to maximize the amount of code in the OS-independent part, and I would try to limit the OS-dependent part to a minimum number of well-defined intra-driver APIs.

Then, and only then, I would rewrite the OS-dependent part as a KDMF or maybe WDM entity. The point is, the cleaner your interface between OS-dependent and OS-independent code, the better off you are and the easier it is to move from OS to OS and from driver standard to driver standard.

Many people look at a driver as a kind of a unified structure under a standard such as WDM or KDMF, but I rather see a driver as code that drives my hardware and just happens to interact with WDM or KDMF when strictly necessary - to me, those APIs are no more than a service layer for me to perform the required interfacing to the OS.

Hope this helps,

Alberto.

----- Original Message -----
From: Bill Simpson
To: Windows System Software Devs Interest List
Sent: Sunday, September 16, 2007 12:19 AM
Subject: RE: [ntdev] Help with Multi-channel PCI Serial I/O driver in KMDF

d,

I’m using a derivative of the PCIDRV source for my prototyping (with significant deltas). The ‘Serial’ sample source was interesting but didn’t seem to deal with the concept of simultaneous streams of data so I didn’t pursue it too far. I’ll relook at it now that you bring it up.

The serial I/O I’m targeting is low/medium rate GPS telemetry data (we launch the GPS satellites for the USAF).
I’m NOT mapping the I/O to the standard COM ports, I’m doing a separate CreateFile(.) for each channel (the way we use to do in NT drivers). Each channel can have independent Win32 threads transmitting and receiving continuous (streaming) telemetry (State of Health) data to/from the GPS vehicles (the data is synchronous RS-422 data & clock).

What you say toward the end of your last email gives me hope that my theory of needing a PDO for each channel makes sense. My only worry is that there seems to be so much more ‘Stuff’ between the DMA transfer I’m use to doing (in my old NT driver code) and the new KMDF. I needed to squeeze all the I/O power out of the old NT systems to get the data processed properly. The idea of having all these FDO/PDO layers worries me re performance.

If I’m required to make a PDO for each channel are you saying that I need to vector all my IOCTL messages through a single Interface GUID then have the FDO forward these messages to the channels (PDOs)? That seems like a bottleneck to me but if that’s the standard then I guess I can give it a try.

I’ve got to say that in the old NT device driver days the concept of multi-channel cards was very common - when I look at the latest sample code, they (MS) actually state that they DON’T cover multi-function (multi-channel) device drivers in the sample code. What’s up with that? In my world there are more and more smart/not-so-smart I/O cards that have 2,4,8,16,32 channels that need to have high independent throughput. Drivers for these puppies will need to be written if we are going to get away from VXWorks.

bill

From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
Sent: Saturday, September 15, 2007 5:07 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Help with Multi-channel PCI Serial I/O driver in KMDF

PCI samples: src\kmdf\PLX9x5x, src\kmdf\pcidrv

Serial: kmdf\serial

As for how to set things up, do you want to expose a separate COM port for each of your channels? If yes, then you must enumerate a PDO for COM port you want to expose. If no, how are the multiple channels addressed by the application?

Assuming you need PDOs for each COM port, you would keep all the resoures in the FDO. You can then choose to fwd all requests to the FDO and process each there or have a private channel between the PDO and FDO (it is the same driver,so this is easy) to “acquire” the appropriate resources for each channel.

d

From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Bill Simpson
Sent: Saturday, September 15, 2007 3:09 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Help with Multi-channel PCI Serial I/O driver in KMDF

Does anybody have any KMDF sample code or expertise that might be of use for porting a multi-channel PCI serial I/O card from an old pre-WDM (NT) driver to KMDF?
I’m having a bit of trouble trying to figure out how to separate out the processing of the card’s multiple channels with respect to the common card resources (DMA, Interrupt, Memory/Register mapping etc.) using FDOs, PDOs. I’m not even sure if I should be using a PDO for each channel and a single FDO for the common stuff.

Any help in the area of how KMDF should deal with PCI cards with multiple independent serial I/O channels in the new KMDF Framework would be much appreciated.

Bill Simpson
xxxxx@braxtontech.com
Braxton Technologies, Inc.
www.braxtontech.com

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

7

Jake,

  1. Thanks, it does answer the ‘what’s up with that’ question and what you
    say makes a lot of sense.

  2. I guess I need to read more on the PDO vs. FDO thing - I must admit I’ve
    only returned to writing drivers this last week (after an 8 year hiatus) so
    I’ve clearly got a lot to learn. Generally I think the WDF/KMDF is
    fantastic and am looking forward to writing (help write) a bunch of drivers
    for DoD hardware - we are moving a lot of functionality from VXWorks, Linux,
    Solaris etc. to XP/Vista in the near future.

  3. agree

  4. Again, I need to read more - I was confused when looking at the Toaster
    code; it seems to create a static list of PDOs based on what I thought was
    analogous individual I/O ports (channels).

Also when you read the WDK docs, the following is presented.

>>

Each bus driver must create a framework device object when it discovers that
a child device is connected to a parent device. The parent device is
typically a bus, but it can also be a multifunction device for which each
function requires a separate set of drivers (such as a sound card that
supports digital audio and MIDI). The device objects that bus drivers create
are called physical device objects (PDOs) because each represents an actual
connection of one piece of hardware (the child) to another (the parent).

<<<

The line ‘the parent device is typically a bus but can be a multifunction
device’ had me thinking that my PCI card (and PLX chipset) was the FDO
(Parent Device) and that each channel was a Physical Device object (a child)
[as in the idea that MIDI, Joystick, and Audio were 3 separate channels
supported by the single (parent) PCI card] - thus my confusion. I must
admit after writing this I still can’t picture how it would be the other way
around. Any suggestions on what I could read to clarify?

  1. Great to know, thanks. BTW: Any chance the source for KMDF will find its
    way to us worker bees anytime soon?

Bill

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Jake Oshins
Sent: Saturday, September 15, 2007 10:10 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Help with Multi-channel PCI Serial I/O driver in KMDF

In no particular order:

  1. The samples have changed over the years, with a greater focus on samples

for hardware that you (and we) might actually be able to play with.

Furthermore, ten years ago (in the NT time frame) we at Microsoft wrote a

relatively large percentage of the device drivers so we owned the code.

These days, if you have a multi-port serial device, it’s very likely that we

didn’t write the driver for that and thus we don’t own the code to give you.

For a while, we just tried to write “samples” that showed the general

concepts, but this code was never executed or tested and it often wasn’t

satisfactory. Today’s samples are (mostly) tested and so they are of higher

value. The problem is that limits them to more generic hardware. Does this

answer your “what’s up with that” question?

  1. You don’t need a PDO for each channel. Doron couldn’t tell from your

response whether you were trying to write driver that exposed COM ports

generically. Your’e not. So you get to pick the interfaces that you

expose. You could just open multiple handles to the same device and

differentiate them somehow. You could append strings to the file name that

you open and parse this part of the namespace in your driver. Or you could

just assume that the first opened handle should be associated with a

particular resource, the second another, etc., though this is a fairly

fragile paradigm. Or you could open a handle and then send an IOCTL on that

handle saying that you want to associate this particular handle with a

particular interface. Or you could create multiple control device objects,

each with a separate name. You choose. It’s your code and your

application. I can’t tell you what’s best without taking a much more

detailed look at your needs.

  1. Similarly, I don’t think that the serial sample is going to do much for

you. That mostly shows you how to expose a “COM” port to the OS.

  1. You’ve got the whole PDO/FDO thing backwards below. If you decide to

create PDOs, they become your upper-edge interfaces. You’d receive requests

on them which would then be forwarded to the FDO, not the other way around.

  1. Lastly, none of these choices have much impact on performance. You’ll do

a little better with fewer layers in your code, but the real bottlenecks

have to do with running data through the processor, or sending and receiving

many IRPs, etc. If you’re doing DMA and you’re designing your

read/write/IOCTL interfaces well, the choices that we’re discussing won’t

have much impact.

  • Jake Oshins

“Bill Simpson” wrote in message

news:xxxxx@ntdev…

d,

I’m using a derivative of the PCIDRV source for my prototyping (with

significant deltas). The ‘Serial’ sample source was interesting but didn’t

seem to deal with the concept of simultaneous streams of data so I didn’t

pursue it too far. I’ll relook at it now that you bring it up.

The serial I/O I’m targeting is low/medium rate GPS telemetry data (we

launch the GPS satellites for the USAF).

I’m NOT mapping the I/O to the standard COM ports, I’m doing a separate

CreateFile(.) for each channel (the way we use to do in NT drivers). Each

channel can have independent Win32 threads transmitting and receiving

continuous (streaming) telemetry (State of Health) data to/from the GPS

vehicles (the data is synchronous RS-422 data & clock).

What you say toward the end of your last email gives me hope that my theory

of needing a PDO for each channel makes sense. My only worry is that there

seems to be so much more ‘Stuff’ between the DMA transfer I’m use to doing

(in my old NT driver code) and the new KMDF. I needed to squeeze all the

I/O power out of the old NT systems to get the data processed properly. The

idea of having all these FDO/PDO layers worries me re performance.

If I’m required to make a PDO for each channel are you saying that I need to

vector all my IOCTL messages through a single Interface GUID then have the

FDO forward these messages to the channels (PDOs)? That seems like a

bottleneck to me but if that’s the standard then I guess I can give it a

try.

I’ve got to say that in the old NT device driver days the concept of

multi-channel cards was very common - when I look at the latest sample code,

they (MS) actually state that they DON’T cover multi-function

(multi-channel) device drivers in the sample code. What’s up with that?

In my world there are more and more smart/not-so-smart I/O cards that have

2,4,8,16,32 channels that need to have high independent throughput. Drivers

for these puppies will need to be written if we are going to get away from

VXWorks.

bill

From: xxxxx@lists.osr.com

[mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan

Sent: Saturday, September 15, 2007 5:07 PM

To: Windows System Software Devs Interest List

Subject: RE: [ntdev] Help with Multi-channel PCI Serial I/O driver in KMDF

PCI samples: src\kmdf\PLX9x5x, src\kmdf\pcidrv

Serial: kmdf\serial

As for how to set things up, do you want to expose a separate COM port for

each of your channels? If yes, then you must enumerate a PDO for COM port

you want to expose. If no, how are the multiple channels addressed by the

application?

Assuming you need PDOs for each COM port, you would keep all the resoures in

the FDO. You can then choose to fwd all requests to the FDO and process

each there or have a private channel between the PDO and FDO (it is the same

driver,so this is easy) to “acquire” the appropriate resources for each

channel.

d

From: xxxxx@lists.osr.com

[mailto:xxxxx@lists.osr.com] On Behalf Of Bill Simpson

Sent: Saturday, September 15, 2007 3:09 PM

To: Windows System Software Devs Interest List

Subject: [ntdev] Help with Multi-channel PCI Serial I/O driver in KMDF

Does anybody have any KMDF sample code or expertise that might be of use for

porting a multi-channel PCI serial I/O card from an old pre-WDM (NT) driver

to KMDF?

I’m having a bit of trouble trying to figure out how to separate out the

processing of the card’s multiple channels with respect to the common card

resources (DMA, Interrupt, Memory/Register mapping etc.) using FDOs, PDOs.

I’m not even sure if I should be using a PDO for each channel and a single

FDO for the common stuff.

Any help in the area of how KMDF should deal with PCI cards with multiple

independent serial I/O channels in the new KMDF Framework would be much

appreciated.

Bill Simpson

xxxxx@braxtontech.com

Braxton Technologies, Inc.

www.braxtontech.com

—

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:

http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at

http://www.osronline.com/page.cfm?name=ListServer

—

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:

http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at

http://www.osronline.com/page.cfm?name=ListServer

—

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:

http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

8

Alberto,

Thanks, I am going to do the same thing re the multiple opens on the
devices.

Also, I agree and am following your approach\philosophy on keeping the OS
dependent and independent code separate.

It does help. Thanks.

Bill

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Alberto Moreira
Sent: Sunday, September 16, 2007 5:20 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Help with Multi-channel PCI Serial I/O driver in KMDF

I allow multiple opens on each of my devices by maintaining a separate
“per_open” structure for each user-side thread. This is a design I inherited
from the previous driver, and it works real well. The serialization is
handled by my chips through per-device hardware queues that can reside
either in host memory or in board memory. Interrupts and Dma are done on a
“per device” basis, the Open handle differentiates the streams.

I also do a lot of MP testing - my favorite testbed is the Dell 490, which
has 4 hyperthreaded processors, that is, 8 effective processors. It’s really
cool to turn on the Task Manager and watch all those performance windows
going! I also do a lot of testing on PowerEdge servers because they come
with four PCI Express slots, which lets me have multiple boards on the same
machine.

I may be rowing against the party-line stream here, but my approach to these
things is to minimize the amount of DDK calls in my code. I much prefer to
drive the hardware myself, specially when I need performance! The way I
would approach this project is this: I would separate the NT driver in two,
an OS-dependent part and an OS-independent part. I would try to maximize the
amount of code in the OS-independent part, and I would try to limit the
OS-dependent part to a minimum number of well-defined intra-driver APIs.

Then, and only then, I would rewrite the OS-dependent part as a KDMF or
maybe WDM entity. The point is, the cleaner your interface between
OS-dependent and OS-independent code, the better off you are and the easier
it is to move from OS to OS and from driver standard to driver standard.

Many people look at a driver as a kind of a unified structure under a
standard such as WDM or KDMF, but I rather see a driver as code that drives
my hardware and just happens to interact with WDM or KDMF when strictly
necessary - to me, those APIs are no more than a service layer for me to
perform the required interfacing to the OS.

Hope this helps,

Alberto.

----- Original Message -----

From: Bill mailto:xxxxx Simpson

To: Windows System mailto:xxxxx Software Devs Interest List

Sent: Sunday, September 16, 2007 12:19 AM

Subject: RE: [ntdev] Help with Multi-channel PCI Serial I/O driver in KMDF

d,

I’m using a derivative of the PCIDRV source for my prototyping (with
significant deltas). The ‘Serial’ sample source was interesting but didn’t
seem to deal with the concept of simultaneous streams of data so I didn’t
pursue it too far. I’ll relook at it now that you bring it up.

The serial I/O I’m targeting is low/medium rate GPS telemetry data (we
launch the GPS satellites for the USAF).
I’m NOT mapping the I/O to the standard COM ports, I’m doing a separate
CreateFile(.) for each channel (the way we use to do in NT drivers). Each
channel can have independent Win32 threads transmitting and receiving
continuous (streaming) telemetry (State of Health) data to/from the GPS
vehicles (the data is synchronous RS-422 data & clock).

What you say toward the end of your last email gives me hope that my theory
of needing a PDO for each channel makes sense. My only worry is that there
seems to be so much more ‘Stuff’ between the DMA transfer I’m use to doing
(in my old NT driver code) and the new KMDF. I needed to squeeze all the
I/O power out of the old NT systems to get the data processed properly. The
idea of having all these FDO/PDO layers worries me re performance.

If I’m required to make a PDO for each channel are you saying that I need to
vector all my IOCTL messages through a single Interface GUID then have the
FDO forward these messages to the channels (PDOs)? That seems like a
bottleneck to me but if that’s the standard then I guess I can give it a
try.

I’ve got to say that in the old NT device driver days the concept of
multi-channel cards was very common - when I look at the latest sample code,
they (MS) actually state that they DON’T cover multi-function
(multi-channel) device drivers in the sample code. What’s up with that?
In my world there are more and more smart/not-so-smart I/O cards that have
2,4,8,16,32 channels that need to have high independent throughput. Drivers
for these puppies will need to be written if we are going to get away from
VXWorks.

bill

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
Sent: Saturday, September 15, 2007 5:07 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Help with Multi-channel PCI Serial I/O driver in KMDF

PCI samples: src\kmdf\PLX9x5x, src\kmdf\pcidrv

Serial: kmdf\serial

As for how to set things up, do you want to expose a separate COM port for
each of your channels? If yes, then you must enumerate a PDO for COM port
you want to expose. If no, how are the multiple channels addressed by the
application?

Assuming you need PDOs for each COM port, you would keep all the resoures in
the FDO. You can then choose to fwd all requests to the FDO and process
each there or have a private channel between the PDO and FDO (it is the same
driver,so this is easy) to “acquire” the appropriate resources for each
channel.

d

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Bill Simpson
Sent: Saturday, September 15, 2007 3:09 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Help with Multi-channel PCI Serial I/O driver in KMDF

Does anybody have any KMDF sample code or expertise that might be of use for
porting a multi-channel PCI serial I/O card from an old pre-WDM (NT) driver
to KMDF?
I’m having a bit of trouble trying to figure out how to separate out the
processing of the card’s multiple channels with respect to the common card
resources (DMA, Interrupt, Memory/Register mapping etc.) using FDOs, PDOs.
I’m not even sure if I should be using a PDO for each channel and a single
FDO for the common stuff.

Any help in the area of how KMDF should deal with PCI cards with multiple
independent serial I/O channels in the new KMDF Framework would be much
appreciated.

Bill Simpson
xxxxx@braxtontech.com
Braxton Technologies, Inc.
www.braxtontech.com

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer</mailto:xxxxx></mailto:xxxxx>