|
发信人: wenbobo(灌了拂衣去) 整理人: wenbobo(2002-09-22 17:48:52), 站内信件 |
| Portability
NDIS drivers should be written so that they are easily portable across all platforms that support Windows 2000 and later operating systems. In general, porting from one hardware platform to another should only require recompilation with a system-compatible compiler. Follow these guidelines for writing NDIS drivers: * Avoid calling operating system-specific functions; instead, use the NDIS equivalents. NDIS exports a rich set of support functions for writing drivers, and by calling these functions, you can port the code between Microsoft operating systems that support NDIS. * Write drivers in C; specifically, the ANSI C Standard. Avoid using any language features that are not supported by other system-compatible compilers. Do not use any features that the ANSI C standard designates as "implementation defined." * Avoid dependencies on data types whose size and layout vary across platforms. For example, do not write driver code that calls any C Run-Time Library functions instead of NDIS-provided functions. * Do not use floating point operations in kernel mode. Attempting such operations will result in a fatal error. * Use #ifdef and #endif statements to encapsulate code used to support platform-specific features. Multiprocessor Support Writing code to safely run on machines with multiple concurrently executing processors is an essential part of writing a portable driver for Windows 2000 and later versions. A network driver must be multiprocessor-safe and must use the provided NDIS library functions. In a uniprocessor environment, a single processor runs only one machine instruction at a time, even though it is possible for a NIC or other device to interrupt the current execution stream when packets arrive or as timer interrupts occur. Typically, when manipulating data structures such as packet queues, a driver disables interrupts on the NIC, performs the manipulation, and then re-enables interrupts. Many threads in a uniprocessor environment appear to run simultaneously but actually run in interleaved time slices. In a multiprocessor environment, processors simultaneously run several machine instructions. A driver must synchronize so that when one driver function manipulates common data structures, the same or another driver function on another processor does not attempt to modify shared data at the same time. All driver code is re-entrant in an SMP machine. To eliminate this resource protection problem, Windows 2000 and later device drivers use spin locks. IRQLs Every driver function called by NDIS runs at a system-determined IRQL, one of PASSIVE_LEVEL < DISPATCH_LEVEL < DIRQL. For example, a miniport driver's initialization function, halt function, reset function, and sometimes the shutdown function commonly run at PASSIVE_LEVEL. Interrupt code runs at DIRQL, so an NDIS intermediate or protocol driver never runs at DIRQL. All other NDIS driver functions run at IRQL <= DISPATCH_LEVEL. The IRQL at which a driver function runs affects which NDIS functions it can call. Certain functions can only be called at IRQL = PASSIVE_LEVEL. Others can be called at DISPATCH_LEVEL or lower. A driver writer should check every NDIS function for IRQL restrictions. Any driver function that shares resources with the driver's ISR must be able to raise its IRQL to DIRQL to prevent race conditions. NDIS provides such a mechanism. ---- 掬水月在手 弄花香满身   
|
|
[关闭][返回] |