2.1 Miniport Design Goals

Miniport drivers allow developers to write code that is specific to the hardware. Functionality that is common across many NIC drivers is provided by the NDIS library. NIC driver writers should write a miniport driver.

While full NIC drivers must handle multiprocessor support and complex synchronization issues explicitly with spin locks and other mechanisms, a miniport usually need not deal with these issues. Consequently, they are much simpler to write and test. The NDIS library functions for miniports(prefaced with NdisM... ) handle these multiprocessor synchronization issues as part of the NDIS library. The following items are merged into the NDIS library for support of miniports:

·Filter packages

·Opens, closes, and queuing of all sorts

·Timers to detect hung hardware

·Synchronization and multiprocessor support

·Support for multipacket sends and receives

·Support for full-duplex operation

Miniports must support one of the NDIS-defined media types. Drivers for other media types must emulate one of these specified media types and run in emulation mode. The NDIS library supports the list of media types noted in Chapter 1 for miniports as well as the NULL filter.

A miniport must meet the following requirements:

Portability

The miniport should call only NdisXxx functions that allow the driver to run on CISC and RISC platforms. The miniport driver must not contain any architecture-dependent code. NDIS shields the driver from architectural differences among microprocessors.

Multiprocessor Support

Any driver must be multiprocessor safe. For most situations, multiprocessor support is automatically provided by the NDIS library.

Functional Requirements

The driver must be able to register itself with NDIS, make requests for operating system support, and allocate, initialize, manipulate, inspect, and deallocate packet descriptors. A packet descriptor is a data structure with both public and private components that contains a pointer to a linked list of buffers.