WDI TLV 剖析器介面概觀

被呼叫端配置模型

驅動程式內的進入點會收到包含 TLV 的訊息或指示。 在程式碼擷取訊息識別碼並判斷它是否為想要處理的識別碼之後，它會呼叫泛型剖析常式，並在進入 WDI_MESSAGE_HEADER) 之後傳遞 TLV blob (，將 TLV 剖析為 C 結構。

ndisStatus = Parse(
    cbBufferLength,
    pvBuffer,
    messageId,
    &Context,
    &pParsed);

檢查傳回錯誤之後，程式碼可以將輸出緩衝區 (pParsed) 轉換成具體類型，例如下列範例所示。

((WDI_INDICATION_BSS_ENTRY_LIST_PARAMETERS*)pParsed)

在呼叫端完成剖析的資料之後，呼叫端必須將記憶體傳回給剖析器。 剖析器必須知道用來配置的原始訊息識別碼，以便釋放正確的資料。

FreeParsed(messageId, pParsed);
pParsed = NULL;

呼叫端配置模型

在此模型中，呼叫端已判斷要剖析的正確特定 TLV，而且可能使用堆疊本機來避免堆積上的配置。 呼叫端會建立本機，並呼叫特定的剖析常式。 API 不需要訊息識別碼，而且參數的型別較不具間接性層級。

WDI_GET_ADAPTER_CAPABILITIES_PARAMETERS adapterCapabilitiesParsed;

ndisStatus = ParseWdiGetAdapterCapabilities(
    cbBufferLength,
    pvBuffer,
    &Context
    &adapterCapabilitiesParsed);

使用 結構完成呼叫端之後，呼叫端應該讓剖析器有機會清除在剖析期間所做的任何配置，並抹除結構，使其準備好重複使用。 參數是強型別的，因此被呼叫端不需要任何其他參數。

CleanupParsedWdiGetAdapterCapabilities(&adapterCapabilitiesParsed);

呼叫 CleanupParse API 之後，結構中的所有資料都無效。

有些訊息沒有任何相關聯的資料。 如需 API 的完整性，會提供適當命名的 Parse 方法。 這些方法會驗證位元組資料流程是否為空白。 Typedefs 會針對參數類型提供，但如果呼叫端使用呼叫端配置模型，則呼叫端也可以傳遞 out 參數的 Null。 在所有情況下，剖析器都會傳回常數空白剖析結構，以避免任何配置。 呼叫端絕對不應該寫入這個傳回的空白結構 (因此唯一的欄位會 命名為_Reserved) 。 這些訊息記載為「沒有其他資料。 標頭中的資料已足夠」。

訊息方向

大部分訊息的 M1 與 M0、M3 或 M4 的格式不同。 為了因應此情況，這類訊息有不同的剖析和產生 API。 針對 M1 訊息，API 會遵循剖< 析 MessageName ToIhv 或產生 MessageName >> ToIhv 的命名慣例。 < 針對 M0、M3 或 M4 訊息，API 遵循剖析< MessageName FromIhv 或產生 MessageName >> FromIhv 的命名慣例。 < 不過，為了簡化 IHV 迷你埠中的程式碼，會將 定義新增至別名 Parse< MessageName 以剖析 MessageName > ToIhv，並產生< MessageName 以產生 MessageName >>< FromIhv。>< IHV 程式碼只有在需要剖析自己的 M3 或產生 M1 時，才需要注意此別名。

錯誤碼

TLV 剖析器產生器可以傳回數個不同的NDIS_STATUS碼。 如需詳細資訊，請參閱 WPP 追蹤記錄。 記錄應該一律指出根本原因。 以下是最常見的錯誤碼清單及其意義。