Restrictions on Intermediate Drivers (NDIS 5.1)
Note NDIS 5. x has been deprecated and is superseded by NDIS 6. x. For new NDIS driver development, see Network Drivers Starting with Windows Vista. For information about porting NDIS 5. x drivers to NDIS 6. x, see Porting NDIS 5.x Drivers to NDIS 6.0.
Previous sections have described specific actions an intermediate driver must follow to perform correctly, summarized as follows:
An intermediate driver must set the NDIS_ATTRIBUTE_INTERMEDIATE_DRIVER flag when it calls NdisMSetAttributesEx in its MiniportInitialize function. NDIS identifies that a driver is an intermediate type only through the presence of this flag.
An NDIS 4.0 or NDIS 5.0 intermediate driver must always, at a minimum, replace an incoming packet descriptor for a packet that it passes down to an underlying driver on a send or up to a higher-level driver on a receive with a fresh packet descriptor, allocated by the intermediate driver. NDIS 5.1 drivers that support packet-stacking do not have this restriction. The NDIS 4.0 or NDIS 5.0 intermediate driver must also then replace its own packet descriptor with the one that originally was associated with the packet when it was passed to the intermediate driver--for example, when completing a send or completing a receive indication. The intermediate driver must return the resources that it has "borrowed" from a higher or lower driver promptly by returning that driver's packet descriptor and the resources that it specifies.
An intermediate driver must follow the rules that apply to any deserialized miniport driver in particular, the following guideline:
If any internal driver resources are shared between an intermediate driver's send function and any other MiniportXxx function, that resource must be protected by a spin lock.
As for any deserialized miniport driver, an intermediate driver that organizes its per-binding context area into discrete receive-specific, send-specific, and shared ranges, with only the shared resources protected by spin locks, will exhibit far better performance than a driver that must overprotect its context area because send-specific, receive-specific, and shared variables are scattered throughout.