1e35c8564a
for Windows are deserialized miniports. Such drivers maintain their own queues and do their own locking. This particular driver is not deserialized though, and we need special support to handle it correctly. Typically, in the ndis_rxeof() handler, we pass all incoming packets directly to (*ifp->if_input)(). This in turn may cause another thread to run and preempt us, and the packet may actually be processed and then released before we even exit the ndis_rxeof() routine. The problem with this is that releasing a packet calls the ndis_return_packet() function, which hands the packet and its buffers back to the driver. Calling ndis_return_packet() before ndis_rxeof() returns will screw up the driver's internal queues since, not being deserialized, it does no locking. To avoid this problem, if we detect a serialized driver (by checking the attribute flags passed to NdisSetAttributesEx(), we use an alternate ndis_rxeof() handler, ndis_rxeof_serial(), which puts the call to (*ifp->if_input)() on the NDIS SWI work queue. This guarantees the packet won't be processed until after ndis_rxeof_serial() returns. Note that another approach is to always copy the packet data into another mbuf and just let the driver retain ownership of the ndis_packet structure (ndis_return_packet() never needs to be called in this case). I'm not sure which method is faster. |
||
|---|---|---|
| .. | ||
| freebsd32 | ||
| ia32 | ||
| linprocfs | ||
| linux | ||
| ndis | ||
| netbsd | ||
| pecoff | ||
| svr4 | ||