Question about ATM miniport driver

Hello £¬

Our corporation is writing a driver of our ATM adapter for Windows 2000, and
we have two questions about it.

As the Microsoft Windows ATM services white paper (Windows98 and windows
2000) said, “Because of this integration and extensive testing, hardware vendors can
focus on their hardware and can largely ignore LANE, IP/ATM, PPP/ATM, Windows
Sockets support, and UNI. Hardware vendors must write only the small NDIS miniport
driver to interface with their hardware because the components formerly required in
the monolithic driver are now folded into the operating system.”

My understanding of these words is that we should only write the miniport
driver of our adapter, and the Call Manager driver and Client of the Call Manager
driver can not be written by us because Microsoft had written them.

Is this understanding right?

The other question is that our Atm adapter doesn’t do the SAR by hardware.
we should do it by software. So where could we put the do-SAR function code?
Can we put it in the miniport driver? Or we must put it in the high-level protocol
driver?

Thank you ¡£

Best Regards!
xhcai


Free Email/SMTP/POP, http://www.bn3.com, Hosting xxxxx@yoursite.com

If your ATM adapter does not do SAR in hardware then you will have to
do the SAR functionality in the NDIS miniport driver. However, if your ATM
adapter
supports a line interface which is faster than E3/DS3(34/45mbps), then you
should stop
right now. You will be getting about 80000-100000 cells per second on a
fully
loaded link and you will absolutely not be able to do software SAR at those
rates.

Dominick Cafarelli

-----Original Message-----
From: encarta [mailto:xxxxx@sjtu.edu]
Sent: Wednesday, February 23, 2000 9:00 AM
To: NT Developers Interest List
Subject: [ntdev] Question about ATM miniport driver

Hello ??

Our corporation is writing a driver of our ATM adapter for Windows
2000, and
we have two questions about it.

As the Microsoft Windows ATM services white paper (Windows98 and
windows
2000) said, “Because of this integration and extensive testing, hardware
vendors can
focus on their hardware and can largely ignore LANE, IP/ATM, PPP/ATM,
Windows
Sockets support, and UNI. Hardware vendors must write only the small NDIS
miniport
driver to interface with their hardware because the components formerly
required in
the monolithic driver are now folded into the operating system.”

My understanding of these words is that we should only write the
miniport
driver of our adapter, and the Call Manager driver and Client of the Call
Manager
driver can not be written by us because Microsoft had written them.

Is this understanding right?

The other question is that our Atm adapter doesn’t do the SAR by
hardware.
we should do it by software. So where could we put the do-SAR function code?
Can we put it in the miniport driver? Or we must put it in the high-level
protocol
driver?

Thank you ??

Best Regards!
xhcai


Free Email/SMTP/POP, http://www.bn3.com, Hosting xxxxx@yoursite.com


You are currently subscribed to ntdev as: xxxxx@nai.com
To unsubscribe send a blank email to $subst(‘Email.Unsub’)

Hi,

Thank you very much.

Luckily our atm adapter is E1 2.048Mbps.

I’m very appreciate your help. And any suggestion about write the SAR

function is welcomed.

xhcai
xxxxx@sjtu.edu

ÔÚ 00-2-24 6:51:00 you wrote£º

If your ATM adapter does not do SAR in hardware then you will have to
do the SAR functionality in the NDIS miniport driver. However, if your ATM
adapter
supports a line interface which is faster than E3/DS3(34/45mbps), then you
should stop
right now. You will be getting about 80000-100000 cells per second on a
fully
loaded link and you will absolutely not be able to do software SAR at those
rates.


Free Email/SMTP/POP, http://www.bn3.com, Hosting xxxxx@yoursite.com

E1 speed is easy. Speed is about 4000 cells per second. I imagine that you
are developing an NDIS 5.0 device driver for Windows 98 or Windows 2000. I
think the Windows 2000 DDK has a sample driver which contains support for a
hardware SAR device. You can use this to determine generic interface issues
with NDIS. However, for doing the SAR functionality in software, here is
what I would do:

During MiniportInitialize, allocate an array of VC connection control
structures which will be used for each open VC connection. This connection
control block will have state variables, CRC32 accumulator, temporary
reassembly buffer[maximum_MTU+1 more cell buffer AAL5 Cell size], control
data required for sending packets. I would think that supporting 16-32
simultaneously open connections should be sufficient for E1. Since you will
need a temporary buffer of about 2k-16kbytes per connection, supporting 256
connections would require quite a bit of memory. Place this connection
control blocks in a free pool using a linked list or stack mechanism.

When Ndis calls your CoCreateVc you will need to get one of your free VC
control blocks described in the previous paragraph. Place this into an open
list of connections. Store the VPI/VCI from the CoCreateVc parameters into
the connection control block.

When Ndis calls your CoActivateVc you will need to find the connection from
the open list of connections and activate this connection. Merely a
semantic.

When Ndis calls your CoDeleteVc you will need to remove the connection from
the open list and place it into the free pool list.

When Ndis calls your CoDeactivateVc you will need to find the connection
from the open list of connections and deactivate this connection.

When you get an interrupt indicating that cells have been received, validate
the PTI field to be 0,1,2,3. If valid, then extract the VPI/VCI from the
cell header, use this and scan your list of open connections, if the VPI/VCI
matches, then copy the cell payload into your temporary buffer, accumulate
the data from the cell into the CRC32 accumulator, if the PTI is 1 or 3,
then this is the last cell. If the last cell, then validate the AAL5
trailer and verify that the CRC32 accumulator indicates a good frame. If
the frame is good, then indicate the frame to Ndis using
NdisMCoIndicateReceivePacket. If the cell is not the last cell, then
determine if the total cells received exceeds the maximum number of cells
for the MTU. If so then reset this connection control block to initial
state because you have max cells error. You do not want to overrun your
temporary buffer.

When Ndis calls your CoSendPackets, you must take the data received by this
function and use it to write cells to your hardware for transmission, set
the PTI field to 0 or 1 depending upon the current cell, accumulate CRC32,
pad out the last cell with 0s and write the appropriate AAL5 trailer.

Hope this helps.
Dominick

----- Original Message -----
From: “encarta”
To: “NT Developers Interest List”
Sent: Friday, February 25, 2000 8:47 AM
Subject: [ntdev] Re: Question about ATM miniport driver

> Hi,
>
> Thank you very much.
>
> Luckily our atm adapter is E1 2.048Mbps.
>
> I’m very appreciate your help. And any suggestion about write the SAR
>
> function is welcomed.
>
>
> xhcai
> xxxxx@sjtu.edu
>
> ÔÚ 00-2-24 6:51:00 you wrote£º
> >If your ATM adapter does not do SAR in hardware then you will have to
> >do the SAR functionality in the NDIS miniport driver. However, if your
ATM
> >adapter
> >supports a line interface which is faster than E3/DS3(34/45mbps), then
you
> >should stop
> >right now. You will be getting about 80000-100000 cells per second on a
> >fully
> >loaded link and you will absolutely not be able to do software SAR at
those
> >rates.
>
>
>
> ____________________________
> Free Email/SMTP/POP, http://www.bn3.com, Hosting xxxxx@yoursite.com
>
> —
> You are currently subscribed to ntdev as: xxxxx@flashcom.net
> To unsubscribe send a blank email to $subst(‘Email.Unsub’)
>
>

Hello,

Can any body provide a sample or document about how to write a port driver
like Scsi Port driver in WinNT or Win 2000? I need to know how a port driver
is hooked to various class drivers like CD, harddisk, scanner drivers.

Thanks in advance

James

All though not perfect this is fairly well covered in the DDk, as well as
Viscarola’s and Mason’s book. There is also an example of a miniport driver
in the DDK, that I have used as a guideline for the driver I’m developing.

-----Original Message-----
From: Zhou, James [mailto:xxxxx@asia.adaptec.com]
Sent: Thursday, March 02, 2000 10:47 PM
To: NT Developers Interest List
Subject: [ntdev] port driver

Hello,

Can any body provide a sample or document about how to write a port driver
like Scsi Port driver in WinNT or Win 2000? I need to know how a port driver
is hooked to various class drivers like CD, harddisk, scanner drivers.

Thanks in advance

James


You are currently subscribed to ntdev as: xxxxx@delphieng.com
To unsubscribe send a blank email to $subst(‘Email.Unsub’)

ATAPI.SYS is the sample you may be interested in. I think it is available in
NT4 DDK but not in 2000 DDK.

<< Hello,

Can any body provide a sample or document about how to write a port driver
like Scsi Port driver in WinNT or Win 2000? I need to know how a port driver
is hooked to various class drivers like CD, harddisk, scanner drivers.

Thanks in advance

James
>>

The ScsiPort driver interface is totally undocumented.

The example Gary refers to, in the DDK, is for a miniport not a scsiport.
Unfortunately, there is no example, spec. or literature that exists
describing how to write Scsi Port driver.

To give a couple of hints:

The scsiport driver combines the functionality of a Bus driver (to enuermate
the LUNs) and a function driver (to handle serializing IO to the LUNs).

-----Original Message-----
From: Gary Little [mailto:xxxxx@delphieng.com]
Sent: Friday, March 03, 2000 7:59 AM
To: NT Developers Interest List
Subject: [ntdev] RE: port driver

All though not perfect this is fairly well covered in the DDk, as well as
Viscarola’s and Mason’s book. There is also an example of a miniport driver
in the DDK, that I have used as a guideline for the driver I’m developing.

-----Original Message-----
From: Zhou, James [mailto:xxxxx@asia.adaptec.com]
Sent: Thursday, March 02, 2000 10:47 PM
To: NT Developers Interest List
Subject: [ntdev] port driver

Hello,

Can any body provide a sample or document about how to write a port driver
like Scsi Port driver in WinNT or Win 2000? I need to know how a port driver
is hooked to various class drivers like CD, harddisk, scanner drivers.

Thanks in advance

James


You are currently subscribed to ntdev as: xxxxx@delphieng.com
To unsubscribe send a blank email to $subst(‘Email.Unsub’)


You are currently subscribed to ntdev as: xxxxx@intel.com
To unsubscribe send a blank email to $subst(‘Email.Unsub’)

ATAPI.SYS is a SCSI miniport driver, not a port driver.

Thanks

James

-----Original Message-----
From: xxxxx@aol.com [mailto:xxxxx@aol.com]
Sent: Tuesday, March 07, 2000 2:32 AM
To: NT Developers Interest List
Subject: [ntdev] Re: port driver

ATAPI.SYS is the sample you may be interested in. I think it is available in

NT4 DDK but not in 2000 DDK.

<< Hello,

Can any body provide a sample or document about how to write a port driver
like Scsi Port driver in WinNT or Win 2000? I need to know how a port
driver
is hooked to various class drivers like CD, harddisk, scanner drivers.

Thanks in advance

James
>>


You are currently subscribed to ntdev as: xxxxx@asia.adaptec.com
To unsubscribe send a blank email to $subst(‘Email.Unsub’)

Oh yeah…I thought you were looking for a miniport sample. Port driver
sample is not available, as far as I know.

<< ATAPI.SYS is a SCSI miniport driver, not a port driver.
>>