Hello,
I have a PCIe based Network device for which I need to develop a driver which should interact with user application and also to the TCP/IP stack of windows.
The application will do data transfer (Read/Write) of some specific type of ethernet frames and send some device control functionality commands. After device receives a frame it copies it to specific location in the device RAM (separate areas for TCP/IP and Application specific frames) and sends a MSI interrupt to the O/S to handle the received frames. The driver should read the Application specific data from device RAM and send it to application and copy the data send by application to this region. Other ethernet frames has to be passed to the windows TCP/IP stack.
The Windows network architecture specifies to use NDIS framework to implement a driver which can interact with the TCP/IP and network devices so we have following architecture :
1.Hardware interface has to be implemented has NDIS miniport having callbacks to NDIS to send/Recieve data.
2.Use NdisMRegisterDevice to create a user application visible symbolic link for Application interface.
3.Using a dll to provide a set of APIs to user application to perform read,write and device control.
- The Dll will transfer the application requests to driver using IOCTLs.
The driver will handle the application specific requests by reading and writing to specific memory areas of the Device RAM and work as a NIC card if no application requests are there using the separate memory area on device for NDIS data exchange.
The target O/S is Windows 7 64bit.
We would like to have comments on this architecture and suggestion for improving it.
This architecture will work or not? I look forward to valuable suggestions from all.
IMHO you don’t need any NDIS here because this thing will not act as a
OS accessible network interface.
– pa
On 19-Jul-2012 17:16, xxxxx@gmail.com wrote:
Hello,
I have a PCIe based Network device for which I need to develop a driver which should interact with user application and also to the TCP/IP stack of windows.
The application will do data transfer (Read/Write) of some specific type of ethernet frames and send some device control functionality commands. After device receives a frame it copies it to specific location in the device RAM (separate areas for TCP/IP and Application specific frames) and sends a MSI interrupt to the O/S to handle the received frames. The driver should read the Application specific data from device RAM and send it to application and copy the data send by application to this region. Other ethernet frames has to be passed to the windows TCP/IP stack.
The Windows network architecture specifies to use NDIS framework to implement a driver which can interact with the TCP/IP and network devices so we have following architecture :
1.Hardware interface has to be implemented has NDIS miniport having callbacks to NDIS to send/Recieve data.
2.Use NdisMRegisterDevice to create a user application visible symbolic link for Application interface.
3.Using a dll to provide a set of APIs to user application to perform read,write and device control.
- The Dll will transfer the application requests to driver using IOCTLs.
The driver will handle the application specific requests by reading and writing to specific memory areas of the Device RAM and work as a NIC card if no application requests are there using the separate memory area on device for NDIS data exchange.
The target O/S is Windows 7 64bit.
We would like to have comments on this architecture and suggestion for improving it.
This architecture will work or not? I look forward to valuable suggestions from all.
I would advise two separate drivers:
-
Miniport one. Its functionality is to interface NIC to the network stack.
-
Protocol one that gets bound only to the target NIC. This driver will be able to send/receive data on NIC by virtue of being NDIS protocol driver. On its upper edge it will expose a standard R/W/IOCTL interface so that your target app will be able to access it.
I think that this is the only correct design. The thing that you suggest simply defies the principles that Windows network architecture is built upon. I guess you are trying to port the design from some other OS where userland calls open() on network devices, right. Therefore, give it up and stick to the ways Windows does things once you are writing a driver for Windows…
Anton Bassov
“OS accessible network interface”
Panel can you please elaborate on this. I cant understand what you mean with this
On 20-Jul-2012 08:03, xxxxx@gmail.com wrote:
“OS accessible network interface”
Panel can you please elaborate on this. I cant understand what you mean with this
It will not act like a network device *for Windows*.
You won’t use it (at least in the mode you’ve described) to browse
internet, connect to network shares and so on? Correct?
– pa
Yes Pavel we dont intend to use it as a network device but for some minimum functionality we will require it to act as NIC card.
On 23-Jul-2012 08:38, xxxxx@gmail.com wrote:
Yes Pavel we dont intend to use it as a network device but for some minimum functionality we will require it to act as NIC card.
Then it does not need to be NDIS. Write the simplest PCI(e) driver that
does the job.