MINIPORT_WDI_TX_TAL_QUEUE_IN_ORDER回呼函式（dot11wdi.h）

發行項
02/06/2025

重要

本主題是 Windows 10 中發行 WDI 驅動程式模型的一部分。 WDI 驅動程式模型處於維護模式，而且只會收到高優先順序修正。 WiFiCx 是 Windows 11 中發行的 Wi-Fi 驅動程式模型。我們建議您使用WiFiCx來利用最新的功能。

MiniportWdiTxTalQueueInOrder 處理程式函式會通知 TAL 目標，指出一或多個暫停的 RA/TID 佇列（具有 WDI_TX_PAUSE_REASON_PS）已準備好傳輸。

這表示：

每個佇列都沒有具有 TAL/target 的未完成 TX 畫面格。
所有以 WDI_TxFrameStatus_SendPostponed 完成 TX 的畫面，都會以正確的順序插入 RA-TID 佇列中。

這是 NDIS_MINIPORT_WDI_DATA_HANDLERS內的 WDI 迷你埠處理程式。

注意您必須使用 MINIPORT_WDI_TX_TAL_QUEUE_IN_ORDER 類型來宣告函式。如需詳細資訊，請參閱下列範例一節。

語法

MINIPORT_WDI_TX_TAL_QUEUE_IN_ORDER MiniportWdiTxTalQueueInOrder;

void MiniportWdiTxTalQueueInOrder(
  [in] TAL_TXRX_HANDLE MiniportTalTxRxContext,
  [in] WDI_PEER_ID PeerId,
  [in] UINT32 ExTidBitmask
)
{...}

參數

[in] MiniportTalTxRxContext

MiniportWdiTalTxRxInitialize中 IHV 迷你埠所傳回的 TAL 裝置句柄。

[in] PeerId

對等標識碼。

[in] ExTidBitmask

擴充 TID 位掩碼。

傳回值

沒有

言論

TAL/target 會先等候此通知，再發出 TX 重新啟動指示給已暫停的佇列，WDI_TX_PAUSE_REASON_PS。

當 TargetPriorityQueueing 為 TRUE 時，不允許注意WDI_TxFrameStatus_SendPostponed，因此當處於該模式時，絕不會提出此要求。

例子

若要定義 MiniportWdiTxTalQueueInOrder 函式，您必須先提供函式宣告，以識別您要定義的函式類型。 Windows 提供一組驅動程式的函式類型。使用函式類型宣告函式有助於驅動程式的程式代碼分析、靜態驅動程序驗證器（SDV）和其他驗證工具尋找錯誤，而且是撰寫 Windows作系統驅動程式的需求。

例如，若要定義名為「MyTxTalQueueInOrder」的 MiniportWdiTxTalQueueInOrder 函式，請使用 MINIPORT_WDI_TX_TAL_QUEUE_IN_ORDER 類型，如下列程式代碼範例所示：

MINIPORT_WDI_TX_TAL_QUEUE_IN_ORDER MyTxTalQueueInOrder;

然後，實作您的函式，如下所示：

_Use_decl_annotations_
VOID
 MyTxTalQueueInOrder(
    TAL_TXRX_HANDLE MiniportTalTxRxContext,
    WDI_PEER_ID PeerId,
    UINT32 ExTidBitmask
    )
  {...}

MINIPORT_WDI_TX_TAL_QUEUE_IN_ORDER 函式類型定義於 dot11wdi.h 頭檔中。若要在執行程式代碼分析工具時更準確地識別錯誤，請務必將 Use_decl_annotations 批註新增至函式定義。 Use_decl_annotations 批注可確保會使用套用至頭檔中 MINIPORT_WDI_TX_TAL_QUEUE_IN_ORDER 函式類型的批注。如需函式宣告需求的詳細資訊，請參閱使用 NDIS 驅動程式的函式角色類型來宣告函式。

如需 Use_decl_annotations的相關信息，請參閱批注函式行為。