NDIS miniport driver question

device driver

    Sponsored Links

    Next

  • 1. Printing drivers architecture
    Hi I've read the information in the DDK about the printing architecture and I have several questions: 1. Is there a better documentation about the printing architecture then the MSDN? 2. Why some printers print in raw and some in EMF? How this decision is being taken after an application is issuing a "Print" command? Is there a way to always produce an EMF file regardless the printer I'm using? 3. My goal is eventually to get an EMF file from each print request, analyze it and block / deny the printing. So, Where in the "chain" is the best place to enter to do such a thing? Thanks
  • 2. Help with Hidd_GetAttributes
    The Hidd_GetAttributes function does not return the information to me of my device USB (they pen drive). It returns all 0. GetLastError returns code 50. Use XP SP2 and VB.net 2005 Some idea? Thanks! PS: CreateFile works OK
  • 3. USB Selective suspend question again
    Is there a possibility of race condition when canceling USB idle request? From the WDK docum ( build 5356): "The following list indicates the 3 most important sets of circumstances in which a driver might cancel an idle request and specifies what the driver must do in each case: (1)The bus driver has not called the USB Idle Notification Callback Routine. The driver must use IoCancelIrp to cancel the idle request IRP. (2)The bus driver has called the USB idle notification callback routine. Drivers must not cancel an idle request IRP within the idle notification callback routine. (3) ... If the device is already in a low power state, it is too late to cancel the idle request IRP ... " Since the bus driver calls the callback at passive IRQL, another thread that tries to cancel the idle IRP needs some way to sync with it ? OTOH if the idle IRP can be canceled in parallel with the callback, but the driver needs to serialize something other (like sending D2 power irp), please say exactly so. Regards, Pavel

NDIS miniport driver question

Postby Gary Chapman » Sun, 16 May 2004 05:57:07 GMT

I have a question about NDIS miniport drivers (The actual vendor supplied  
NIC driver)

In most of the documentation about NDIS it looks as though the NIC driver  
communicates with the network card via the NDIS wrapper.  In other  
documentation it would appear that the NIC driver has to go via the NDIS  
hook driver, the NDIS wrapper and then the NDIS hook driver again to reach  
the NIC.

I have looked at my own driver on Win2k, and another driver on Win98, with  
a dependency checker.  Both appear to call the following functions  
exported from HAL.DLL:

KeStallExecutionProcessor()
READ_PORT_UCHAR()
READ_PORT_ULONG()
READ_PORT_USHORT()
WRITE_PORT_UCHAR()
WRITE_PORT_ULONG()
WRITE_PORT_USHORT()

This leaves me a little bit confused as it would seem that the NIC driver  
uses HAL.DLL to talk to the hardware, rather than going back through  
NDIS.SYS.

So, my question:

Is it true that NDIS completely wraps the NIC driver at both the upper and  
lower edge (As indicated by various architecture diagrams from microsoft,  
PCAUSA, etc.)  Or does the NIC driver call the READ_PORT, WRITE_PORT  
functions of HAL.DLL who in turn talks to the hardware without ever going  
back through the NDIS wrapper or NDIS-hooking filters.

To see an example of the architecture diagrams that are confusing me  
please check out the image at the following link:  
 http://www.**--****.com/ 

Any help or pointers on this would be appreciated.

Many thanks in advance,

GC
-- 
Using Opera's revolutionary e-mail client:  http://www.**--****.com/ 

Re: NDIS miniport driver question

Postby Don Burn » Sun, 16 May 2004 06:17:38 GMT

Well, NDIS does wrap things but some of the wrappers are quite thin, for
example

#define NdisWritePortUchar(Handle,Port,Data)
\

WRITE_PORT_UCHAR((PUCHAR)(NDIS_PORT_TO_PORT(Handle,Port)),(UCHAR)(Data))

#define NdisStallExecution(MicroSecondsToStall)
KeStallExecutionProcessor(MicroSecondsToStall)

So you can see how the driver calls the HAL even if the names are different.
Things get more confusing if the driver is an NDIS WDM driver where all of
the normal WDM calls are available.

Good news is that in the future the network support (and other miniports for
that matter) will become integrated into the new WDF model in a cleaner
fashion.  There will only be one name for a function, and the miniport stuff
will provide environment specific support, not generic stuff such as locking
they currently do.


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









Re: NDIS miniport driver question

Postby Stephan Wolf » Sun, 16 May 2004 06:22:10 GMT

NDIS has originally been defined to be platform-independent from both
processor and operating system. A properly written NDIS driver would
recompile for any target platform without any changes (in theory).

Properly written NDIS driver must not use any system-specific
functions. Period. The NDIS Wrapper thus is the only interface between
an NDIS driver and the system.

However, the "Windows on x86" platform defines some of the NdisXxx()
functions to be macros that directly map to Windows system functions.
Some of them are the ones that you mention.

See <ndis.h> for the definition of the NdisRead/WritePortUxxx()
macros. For instance, NdisReadPortUchar() maps to
NdisRawReadPortUchar(), which again maps to READ_PORT_UCHAR().

Note that READ_PORT_UCHAR() etc. are *not* exposed by Windows 9x/Me
itself but are there in NDIS.VXD (IIRC) so binary-compatible NDIS
drivers can be created (see also
 http://www.**--****.com/ ).

Note also that things may change in upcoming versions of NDIS in that
the platform-independency will no longer be there (sigh).

HTH, Stephan
---
On Fri, 14 May 2004 21:57:07 +0100, "Gary Chapman" < XXXX@XXXXX.COM >




Re: NDIS miniport driver question

Postby Gary Chapman » Sun, 16 May 2004 07:02:51 GMT

o, the drivers I have looked at (who appear to depend upon, and directly
call, the HAL.DLL library) were actualy written to be dependent only on
NDIS.SYS. However, during compilation for my platform certain NDIS.SYS
calls were mapped to HAL.DLL Do I have that right ?

Presumably the same driver compiled on another platform may not call
HAL.DLL at all.

Did I understand you correctly ?

That certainly clears up my confusion. Many thanks to all those who
replied to my original post. And wow are you guys are fast!

GC

On Fri, 14 May 2004 23:22:10 +0200, Stephan Wolf < XXXX@XXXXX.COM >
wrote:




--
Using Opera's revolutionary e-mail client: http://www.opera.com/m2/

Re: NDIS miniport driver question

Postby bburgin » Sun, 16 May 2004 15:30:02 GMT

To build a cross-platform driver, you define BINARY_COMPATIBLE.  This 
ensures that those "functions" that are macros (NdisREquest, NdisSend, etc) 
become true calls into the NDIS library.  You don't need to do this if 
you're building a miniport driver because when you define NDIS_MINIPORT, 
Binary Compatible is automatically defined.

For those "functions" (macros) that end up actually importing system 
functions, in Windows 98/ME, those functions are resolved by NtKern.VxD.

For cross-platform NDIS development, see my 2001 WinHEC presentation at 
 http://www.**--****.com/ 
Platform Drivers: NDIS Case Study under WinHEC 2001 Driver Development 
Sessions.

Bryan S. Burgin
 XXXX@XXXXX.COM 

This posting is provided "AS IS" with no warranties, and confers no rights.
{\rtf1\ansi\ansicpg1252\deff0\deflang1033{\fonttbl{\f0\fnil\fprq2\fcharset0 MS Sans Serif;}}
\viewkind4\uc1\pard\f0\fs20 To build a cross-platform driver, you define BINARY_COMPATIBLE.  This ensures that those "functions" that are macros (NdisREquest, NdisSend, etc) become true calls into the NDIS library.  You don't need to do this if you're building a miniport driver because when you define NDIS_MINIPORT, Binary Compatible is automatically defined.
\par 
\par For those "functions" (macros) that end up actually importing system functions, in Windows 98/ME, those functions are resolved by NtKern.VxD.
\par 
\par For cross-platform NDIS development, see my 2001 WinHEC presentation at  http://www.**--****.com/ : NDIS Case Study under WinHEC 2001 Driver Development Sessions.
\par 
\par Bryan S. Burgin
\par  XXXX@XXXXX.COM 
\par 
\par This posting is provided "AS IS" with no warranties, and confers no rights.
\par 
\par }

Re: NDIS miniport driver question

Postby Maxim S. Shatskih » Sun, 16 May 2004 19:13:47 GMT

> In most of the documentation about NDIS it looks as though the NIC driver

This is done for convinience, and for portability to machines where explicit
pipeline/barrier flushes are necessary on hardware register accesses.


So what? The usual forwarder export. The same way in user mode
kernel32!HeapAlloc is forwarded to ntdll!RtlAllocateHeap.

This was done just for NDIS.SYS author convinience and for a small speed
advantage.

-- 
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
 XXXX@XXXXX.COM 
 http://www.**--****.com/ 



Similar Threads:

1.NDIS Miniport Driver Question

If I write my own NDIS miniport driver, can I circumvent Microsoft's current
restrictions on TCP and UDP sockets? In particular, would it be possible to
to allow raw socket support (in both TCP and UDP), and to allow more thasn
10 half-open connections (in TCP)?

TIA.
Rob


2.NDIS miniport driver question...

Hi all,

I've written a miniport driver and I have noticed, the OIDs
OID_GEN_TRANSMIT_BUFFER_SPACE and OID_GEN_RECEIVE_BUFFER_SPACE never
been called.
Anybody know why is it so?

Also, I noticed the TCP windows size is decreasing continuously as the
traffic increased. Sometimes it reaches zero, though it recovers again
but it will not go back to the maximum windows size. Any suggestion on
this?

I have added the following register entry, still the behavior is same.

[HKEY_LOCAL_MACHINE\Comm\Tcpip\Parms]
"TcpWindowSize"=dword:10000
"Tcp1323Opts"=dword:3


Regards,
Raghav

3.Ndis miniport syncronisation question

On a serialized miniport running on SMP system, which on the MiniportXXX
functions can be preemted by another call to a MiniportXXX function, and,
which of the MiniportXXX function are guaranteed to not be preemted?


4.Questions about NDIS miniport driver - E100bex

Recently I read XPDDK's sample E100bex. I have two questions about the calls
of NdisMAllocateMapRegisters and NdisMAllocateSharedMemory in initialization
phase.

1) In SetupSharedAdapterMemory routine, it calls NdisMAllocateMapRegisters
to allocate map registers. By the default value,
Adapter->NumMapRegisters = Adapter->NumTbd = (Adapter->NumTcb *
Adapter->NumTbdPerTcb) = 16*8=128
and Adapter->MaxPhysicalMappings = MAXIMUM_ETHERNET_PACKET_SIZE = 1514.
So the total number of map register to be allcated is 128 * 2 = 256.
However, XPDDK's help says "NDIS imposes a limit of 64 map registers per
miniport driver."
I'm confused. I have no hardware device of e100bex, so I don't run it to
know the actual number of map registers.

2) I want to know the relationship between the number of map registers that
NdisMAllocatemapRegisters allocates and the length of shared memory that
NdisMAllocateSharedMemory allocates. In other words, does the number of map
registers limit the length of shared memory to be allocated subsequently.

Thanks
Zhou


5.NDIS miniport reset questions

Hi everybody,

I have some questions with respect to NDIS miniport reset.

- In addition to Check4Hang what are the other options to notify NDIS
that we are under a reset process?

- What would be the impact of the reset on NDIS with respect to the
following:

   - Will it stop transferring packets/OIDS to the miniport?

   - Will it notify the protocols drivers?

   - Is there a limit to the time we are allowed to be in reset
process?

- How would the protocol drivers (especially TCP/IP) behave, in that
case? will they stop   sending packets/OIDS to NDIS until they are told
that the reset is done?

  Thanks
  Miki

6. Question Regarding NDIS-Miniport Driver

7. NDIS Miniport Crash in NDIS!ndisMSendComplete

8. NDIS packet tracer from application till NDIS miniport ?



Return to device driver

 

Who is online

Users browsing this forum: No registered users and 67 guest