（7）高通AP10.4开发者指南——WLAN（2.1 主要数据结构）

2 WLAN驱动设计

这个章节主要介绍了大体的WLAN驱动设计思路。所有驱动支持的功能，将在后续章节有更深入的描述。

2.1 主要数据结构

整个WLAN驱动的处理和各模块间的访问，主要通过下面的数据结构来完成的。每一层都有自己的数据结构，对这些层的访问，必须通过这些层提供的API，并封装其对应的数据结构来进行。全程是没有全局数据的，这样也使WLAN驱动能够支持不同的AP平台配置，比如多radios、同一radios的多BSS等。

图 2-1 表述了WLAN驱动各层次的主要obj，以及他们之间的联系。后续章节会对这些内容的细节进行说明。

图 2-1 WLAN驱动主要的Obj

2.1.1 系统接口（OSIF）数据结构

2.1.1.1 ath_softc_net80211

ath_softc_net80211是一个面向radio设备的数据结构。在OSIF层内部被缩写为“scn”。
这是驱动为每一个AP平台内的WLAN radio接口，提供的一个系统接口的抽象。这个结构映射了网络协议栈提供的网络设备私有数据结构。主要映射“wifi”接口。下面这些是一些存储在这个结构中的数据：

• UMAC通用的设备结构
• 面向LMAC设备的句柄（handle）
• LMAC接口函数
• OS设备句柄（handle）
• 同步锁
• node到key index映射的引用

2.1.1.2 osif_dev

osif_dev是一个OS接口设备结构体。他被定义成os_if_t类型，并在OSIF层内部被缩写为“osdev”。
这个是OS接口抽象，由驱动提供，用于每个由系统创建的WLAN网络接口。这个结构体通过OS栈，映射网络设备的私有数据结构。这个结构体，帮助维护OS结构层的网络设备驱动信息。这个obj在网络栈上映射“ath”接口。一些在这个结构体中维护的数据有：

• 对网络设备的引用
• 对父类网络设备的引用
• 间接指向UMAC wlan接口的指针——用于UMAC API调用
• 间接指向UMAC通用接口（radio结构）——用于UMAC API调用
• VlanID和vlgrp
• UMAC连接状态机的句柄和扫描相关的句柄

2.1.2 UMAC数据结构

2.1.2.1 ieee80211com

ieee80211com是UMAC radio设备结构体。被定义成wlan_dev_t结构体类型，并在UMAC中被缩写为“ic”。
UMAC对所有radio相关的信息进行了抽象，并放在ieee80211com结构体中。这些数据对所有网络接口通用。由底层共享出来的状态信息和UMAC层，暴露在这里。
存储在这个结构体中的信息有：

• 间接的osdev的handle
• 到scan table和scanner object的引用
• 所有的UMAC网络结构object的list
• 所有的用于连接管理的UMAC Node object（指向Node table的指针）的list
• 访问设备参数和数据的函数指针（API）

2.1.2.2 ieee80211vap

ieee80211vap 是一个UMAC网络接口结构体。每一个WLAN网络接口在UMAC中用“Virtual AP” (VAP) 来表示，每一个结构都有一个底层物理设备对应。每一个VAP都可以有很多操作模式，比如host Access Point、IBSS或者Station模式。每个VAP都有对应的OS设备，可以用于数据流以及供用户空间程序使用。这个部分包含的信息有：

• 间接的osdev的handle
• BSS node引用
• 所有的VAP相关的数据结构

2.1.2.3 ieee80211_node

UMAC Node结构体. 结构体类型为wlan_node_t通常在UMAC中缩写为“ni”。可以代表一个infrastructure网络中的BSS，或者一个IBSS模式下的ad-hoc station，或者在HOSTAP模式下一个已连接的station。对ieee80211_node的设置可以表明设备在网络中的本地视角。比如一个在station模式的设备，唯一的ieee80211_node对象，是和这个设备连接上的对端AP。而一个在AP模式的设备，对ieee80211_node对象的设置，代表了对当前BSS的station的设置。对于一个在ad-hoc模式的设备，对ieee80211_node对象的设置代表了可见的邻近设备（不论在不在IBSS内）。

2.1.3 LMAC数据结构

2.1.3.1 ath_dev: LMAC device结构体

定位为ath_softc，结构体类型为ath_dev_t（不被其他层直接访问）。在LMAC内部代码被缩写为“sc”。
LMAC将底层的驱动组建，封装成一个Qualcomm Atheros设备对象。ath_dev对上层不直接可见，需要通过一些定义好的函数表（ath_ops）来访问，即LMAC API。这样的好处是，不论底层硬件是什么，协议栈都可以通过这些API以相同的方式，对设备对象进行访问。比如，协议栈通过通过相同的方式来访问PCI设备或USB设备，不必担心硬件上的不同。

2.1.3.2 ath_vap: LMAC vap结构体

在LMAC中被称为“vap”。每个ath_vap对象代表一个VAP(virtual AP)实体。这个对象直接对应UMAC中的ieee80211vap对象。默认情况下，每个物理设备都只有一个VAP实体，根据需求可以通过协议栈增加或删除VAP。每个ath_vap可以通过一个唯一的index被其他层访问。Qualcomm Atheros硬件最多可以支持16个VAP，所以有效的index范围是0到15。

2.1.3.3 ath_node: LMAC node结构体 (对应每个UMAC node)

定义成ath_node_t类型，在代码中缩写为“an”。每个ath_node对象代表了和他对应的ieee80211_node对象，相关结点信息存储在LMAC中。和ath_dev相同，每个ath_node不直接暴露给其他层，也是需要通过ath_ops表来访问。

2.1.4 HAL Data Structures

2.1.4.1 ath_hal: HAL device结构体

在代码中被缩写为“ah”。设备中的HAL client调用ath_hal_attach来得到ath_hal数据结构。和硬件相关的操作，必须作为call back函数，通过第一个参数传递给HAL。这个结构体抽象了一些底层硬件芯片相关的数据结构，用于上层使用，并提供了一些通用的接口。实际每个设备相关的HAL结构体，根据不同的硬件芯片类型，是分开定义的（比如ath_hal_9300，ath_hal_5416，和ath_hal_5212）。